Jade Backups

[ConvertFromOldNGs]

by Glen Richards >> Wed, 11 Feb 2004 2:36:43 GMT

2 Questions regarding backups:

1) Is there an easy way to detect whether a Jade system is in backup state? I.e. if system.isInBackupState() then...

2) On our Jade system we use a large number of map files. When we backup our database using the JadeDatabaseAdmin class, it reports that a number of files were not backed up. These files have never been needed, so no problems - but why does it do it? My guess is that no instances for a particular map/dat file exist, so that file doesn't get backed up.

Does anyone know the details of exactly what's going on here & have any suggestions for getting this to stop happening? I've been aware of this one for a long time, but have never worked out exactly what's going on.

If anyone could point me to existing documentation on this, that would be great too.

Any help appreciated, cheers,


Glen
Encos

[ConvertFromOldNGs]

by allistar >> Wed, 11 Feb 2004 7:54:42 GMT

2 Questions regarding backups:

1) Is there an easy way to detect whether a Jade system is in backup state? I.e. if system.isInBackupState() then...

Not that I am aware of. It would make sense to have your global exception handler specifically trap this situation though. If you have coded the online backup as a part of your application then you could always set a property to "true" when the backup starts and back to "false" when it finishes. Not very nice I know but it would work.

2) On our Jade system we use a large number of map files. When we backup our database using the JadeDatabaseAdmin class, it reports that a number of files were not backed up. These files have never been needed, so no problems - but why does it do it? My guess is that no instances for a particular map/dat file exist, so that file doesn't get backed up.

That implies that the map file has been setup (i.e. it has been defined) but it doesn't exist because no instances of any classes that are in that mapfile have been created. I can think of three ways around this: 1) remove the mapfiles if they are not needed. 2) create an instance of an object in each mapfile and then delete that object again. 3) ignore the message during the online backup - that's what we do, it's an innocuous message.

Does anyone know the details of exactly what's going on here & have any suggestions for getting this to stop happening? I've been aware of this one for a long time, but have never worked out exactly what's going on.

If anyone could point me to existing documentation on this, that would
be great too.

Any help appreciated, cheers,

Regards,
Allistar.
--
------------------------------------------------------------------
Allistar Melville
Software Developer, Analyst allistar@silvermoon.co.nz
Auckland, NEW ZEALAND

Silvermoon Software
Specialising in JADE development and consulting
Visit us at: http://www.silvermoon.co.nz
*NEW* Simple web access to Jade at: www.silvermoon.co.nz/jhp.html ------------------------------------------------------------------

[ConvertFromOldNGs]

by Torrie >> Wed, 11 Feb 2004 8:52:30 GMT

We check the size of the database files before we back them up. If the file is empty we don't back them up (see code below.) If you use the backupDbFiles or backupAllDbFiles methods then you can check the size of the files in the droppedFiles collection prior to reporting them. (See the help on backupAllDbFiles)

Torrie

// Start the backup
zhmlMyDBA.getDbFiles( pfileKinds, dbFiles );

foreach dbFile in dbFiles do
if dbFile.excludeFromBackup then
// Since we have enumerated environmental files, we must exclude files // whose excludeFromBackup attribute is set; for example, _locks.dat and // _environ.dat
elseif dbFile.getFileLength = 0 then
// DB file is empty so no need to backup
else
// Need to backup this file.
dbFile.backupFile(pbackupDir, pverifyFiles, pcompressFiles, poverwriteFiles);
endif;
endforeach;

[ConvertFromOldNGs]

by Dr J. >> Wed, 11 Feb 2004 21:17:50 GMT

Another option I've used previously is to do a <class>.firstInstance on one of the classes mapped to a file that does not yet exist. This has the nice side-effect of creating the mapfile in order to process the firstInstance method and removes the need to check/handle mapfiles that do not yet exist in your backup routines.