As you can see from the messages below there appears to be a "problem" with the BACKUP command.
When I first e-mailed RDCC on Saturday I had thought that it only occurred with a specific set of circumstances. After getting their reply on Sunday I made the change where I now knew my code to be wrong and everything was fine again. (Note the days - thanks RDCC/RBTI for the speedy response.) Unfortunately, since then I have discovered on checking all my other output files that there appears to be a more general problem and BACKUP does seem currently to always produce a zero-length file - but the .LOB looks okay size-wise. I can find no mention in any of the recent updates that refers to the BACKUP command being made obsolete or changed but if I have missed something then I apologise now. However, if you are (still) using BACKUP to save your data it may be worth checking to see if the files produced are as you would expect. I am using W98SE so it may only be a problem specific to that O/S. Nevertheless, being paranoid about having good backups I thought a warning to all to be worthwhile. Regards, Alastair. NB: I have also found good BACKUPs dated 26/08/2004 rather than the earlier date I gave below. ----- Original Message ----- From: "Alastair Burr" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Sunday, September 19, 2004 8:14 PM Subject: Re: Backup from sys_forms/reports produces zero length file > Many thanks. > > Has this been changed? The example in the help for BACKUP shows: > > The following command lines show how to transfer a form to a new database. > The first five command lines open the olddb database, set the null value > to -0-, create the TEMPFORM.DAT file on drive D:, back up the data from the > sys_forms2 table that contains the definition of the oldform form, and > redirect the output to the screen. Command lines six through eight open the > newdb database in order to transfer the oldform form definition (the > database you open must not have a form named oldform), set the null value > to -0-, and load the form definition from the backup file into the > sys_forms2table. > > CONNECT olddb > SET NULL -0- > OUTPUT d:tempform.dat > BACKUP DATA FOR SYS_FORMS2 WHERE SYS_FORM_NAME = 'oldform' > OUTPUT SCREEN > CONNECT newdb > SET NULL -0- > RUN d:tempform.dat > > > It's no problem to change it but it was working and the above will probably > mislead others... > > Regards, > Alastair. > ----- Original Message ----- From: "RBG7 RDCC Staff" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Sunday, September 19, 2004 4:35 PM Subject: Re: Backup from sys_forms/reports produces zero length file > > Dear Alastair, > > The correct syntax: > > UNLOAD DATA FOR Sys_Forms3 where sys_form_name = 'AllCopy' > > We thank you for your feedback. > > RBG7 R:DCC Staff. > ============== > > > At 05:52 PM 9/18/2004 +0100, you wrote: > > >Hi, again - it looks like being one of those weekends! > > > >This set of commands has started producing the FileName.fle with no data > >in it although the .LOB file looks to be the expected size: > > > >OUTPUT FileName.fle > >BACKUP DATA FOR Sys_Forms3 where sys_form_name = 'AllCopy' > >OUTPUT SCREEN > > > >It happens with reports as well. > > > >I think it must have started some time ago as I have a procedure that > >backs up forms and reports based on data in the sys_comment column and the > >last good data is dated 17/08/2004. It has worked well for years so I > >don't often check the output anymore. > > > >Again, if this is in update #78 then apologies. Perhaps it would be useful > >to be able to view the "whatsnew" file without having to run the upgrade > >then it could be seen if what looks like new problem(s) have already been > >taken care of? > > > >Regards, > >Alastair. > > > >---------------------------------- > >A D B Burr, > >St. Albans, UK. > >---------------------------------- > ><mailto:[EMAIL PROTECTED]>[EMAIL PROTECTED] > >---------------------------------- >
