Escaping chracters on batchfiles

egleuk

We just bought SQL Backup, and now I try to automate the backup jobs in a Windows Batchfile (*.bat). The building of the batchfile works fine up to the encrypted password. No problems when the password is put in plaintext, but when we try an encrypted password, we receive an error: "The system cannot find the file specified" or something similar. This is part of the job I created:

:: Handle password component

   if %5 == 0 set enc=
   if not %5 == 0 set enc=''<ENCRYPTEDPASSWORD>1h7h15b8i9s8jg3sa7dh4</ENCRYPTEDPASSWORD>''
   if %5 == 1 set enc=%enc%, KEYSIZE = 128,
   if %5 == 2 set enc=%enc%, KEYSIZE = 256,

The password part is copy/pasted from the GUI, parameter number 5 contains either 0 (no encryption), 1 (128 bit) or 2 (256 bit). The whole backup/restore commands are created by concatenating pieces of string like this one.

The < and > characters are considered redirection operaters I guess, so I need to escape them. Microsoft tells me that special chars like <, >, etc should be escaped by putting a ^ character in front of the special character like this: ^<ENCRYPTEDPASSWORD^>. Looks like that doesn't work on Windows 2003 Server SP1.

Is there a work-around, like using another syntax than the XML-style from the GUI?

Brian Donahue

Hi,

I think there is a slight difference in the way the command prompt uses escape characters interactively versus in a batch file. I've used the hat ^ before, so I know that is a valid escape character, but have you tried the backslash (\) as well? This works in C programming and also, I believe, in batch files.

egleuk

Hi Brian,

Thanks for replying at this short notice. I've tried the hat ^, the backslash \ and some other possibilities like assigning the content of a file (containing just the > or < charachter) to a variable, but nothing works.

I just spent another hour on searching the net, trying several solutions that worked in MS-DOS5.0, MS-DOS6.22 environments based on reports from old MSDOS guru's that might also work on Win2003 Server. I suppose there is not another way to specify an encrypted password? That is my only problem, the rest works fine.

Incredible that there's no solution to such a tiny problem ...

Regards,
Erik

Brian Donahue

Hi Erik,

I hope that this script doesn't do a restore database job, that may explain this because as of version 4, encryptedpassword tags were only supported for backup jobs, not restore jobs.

egleuk

I have not scripted the restore using an encrypted password. Will that be supported in version 5?

----

Could you also answer this question: I am testing on a "test" machine using the 14-day trial version. That period is almost over. I'd like to use one of the licenses we bought, but I also know that this server needs restaging after I completed the tests. Restaging: a complete re-install of Win2003 + SQL2005.

Would the key I receive from you still be valid for this server AFTER I restage the machine? Or will we lose that license by restaging the machine? If not, I could stop worrying about the end-of-trial in a few days. And I will certainly need a few more days to complete all tests.

Brian Donahue

I had just given this a try and it seems to work without the escape characters, anyway. I think the problem could be that you have got the whole Encryptedpassword thing inside a twin-set of single-quotes. It works on my computer if I only use one single-quote, ie:

SQLBackupC.exe -E -I XXXX -SQL "BACKUP DATABASE [XXXXX] TO DISK = 'D:\sql2005\MSSQL.1\MSSQL\Backup\<AUTO>.sqb' WITH COMPRESSION = 1, KEYSIZE = 256, PASSWORD = '<ENCRYPTEDPASSWORD>XXXXXXXX==</ENCRYPTEDPASSWORD>'"

When you get to the end of the trial, the software will stop working. It would be possible to transfer the licence from another server, but you may want to contact our sales people if you want to go that way, as they may need to free up an activation for you. It is possible to renew a trial, but I don't want to put that information here; the best thing to do, again, would be to ask sales (sales@red-gate.com)

Thanks!

petey

Encrypted passwords are not supported in version 5 either. This is to prevent situations where someone who knows the encrypted password used for the backup, uses the same encrypted value for the restore, without having to know the actual password.