GUI Job Editing Inconsistency

laurencerooks

I love the new GUI interface for v5.1, which allows you to create, modify, and delete backup jobs on remote servers from one central location. The problem I'm experiencing though is inconsistency with being able to edit them the next day. There are some servers that will allow me to edit the jobs the next day and some that don't. Has anyone experienced this? If so, do they have a resolution?

Laurence

cgriffin

I'm having trouble editing ANY jobs this morning. The only thing I did differently yesterday was to manually edit my step scripts via Enterprise Manager/Management Studio because the SQLBackup GUI doesn't allow you to set a delete files timeframe for the 'copy to network' option. I have removed the code I added on a couple of jobs but it still won't let me edit. Sounds like a permissions thing but I haven't figured it out yet.

cgriffin

'Cannot edit command' window pops up with the message 'The GUI does not support editing the command you selected'. Still can't edit any existing jobs. Any help is appreciated.

Brian Donahue

Thanks for writing. It looks like the backup jobs need to meet a pretty strict template and some manual job editing seems to break it. I'll get this looked into.

cgriffin

That's kinda what I figured, but I didn't see any other way to add that 'fileoptions' and the documentation says we can use it.

Dan J Archer

You're quite right, that option is entirely allowed, but it's one of the ones that the GUI can't edit.

The GUI doesn't attempt to edit jobs that don't conform to a relatively strict syntax. This is primarily to avoid fringe cases where the GUI might think it can successfully edit your job, but could end up losing advanced syntax when saving it back. We figured that preserving the integrity of the job as is is more important than always being able to edit from the GUI.

If there are particular options you'd really like to see in the GUI, feel free to post on here letting us know. The more people tell us, the more leverage we have when it comes to trying to get such features into future release.

Thanks very much,

Dan

Dan J Archer
Red Gate Software

cgriffin

I understand completely about the integrity of the job, but the problem is, even after I put the job back the way it was originally established, the GUI still can't edit.

I don't recall seeing any kind of 'heads-up' about this situation when researching the available options not supported by the GUI. It's almost as if we were being told to go ahead and use all these great options while not being told about the editing problem. In an environment where a single SQL administrator goes on vacation or quits his/her job, someone with less SQL knowledge needs the GUI to work. That speaks to the quality of SQL Backup's GUI. I don't want anyone but a SQL admin messing directly with SQL scripts in the SQL agent on my systems.

As for future options, I'll add my vote to be able to manage backup copies, and being able to independently set ERASEFILES to different amounts.

cgriffin

And thanks for the support replies. I'm not ready to deploy 5.1 to any more servers until the bugs are worked out, but I'm not getting rid of it either. Still a good product.

laurencerooks

I agree with cgriffin. I think we need to have the ability to edit the jobs created by SQL Backup. It provides a simple interface that we can create a simple manual off of for when we are on vacation and someone with less experience needs to access the jobs. I love the new GUI, but it does have its shortcomings, such as being able to edit a job after you create it and reboot your workstation. Also, we can install the server components remotely but we can't remove them remotely. Is there a place we can make suggestions?

Laurence

laurencerooks

I'm back and I'm still convinced this is a bug and not a security feature. We should be able to edit all jobs all the time through the GUI on a remote master workstation/server because of the following scenarios:

1. I have 13 production servers, 3 of which I am able to edit, 10 of which I am not able to edit.
2. I don't see a difference between servers on the surface that jump out at me pointing to the reason why I can edit Server 1 and not Server 2.
3. This only occurs after you restart the workstation/server the GUI resides on.
4. I have another co-worker at an site in Europe that ran into the same issues of being able to create a job, tinker with it all day long, and unable to mess with it the next day.

It would be different story if I wasn't able to edit any server, then I would say it could fall under the security feature aspect. But that's not the case. Can someone please look into this? It has to do with the remote aspect of it because you can edit all day long if the GUI is directly on the SQL Server in question, so it's not a GUI issue.

Thanks,

Laurence

cgriffin

Laurence, I'm not able to edit the SQL2005 job on the server on which the GUI is installed. According to Dan Archer, it has to do with the way SQLBackup treats jobs that are edited by something other than the GUI.

laurencerooks

Son of a gun. Thanks cgriffin. I think I know why we're having our issues on certain servers and not on others.

Laurence

cgriffin

laurencerooks wrote:

Son of a gun. Thanks cgriffin. I think I know why we're having our issues on certain servers and not on others.

Laurence

Is it because you've used the GUI exclusively on some and not on the others?

laurencerooks

It's because the previous DBA set up a job that runs on a nightly basis and adds an email notification step to each job that doesn't have it. Some servers that were created or modified after his departure don't have this job running on it, which explains why I can modify them with the GUI and not the others.

Laurence