Trying to migrate my DBISAM 4.34 to ElevateDB.

During the course of that migration my database was created by the
"ElevateDB Manager (Unicode)".

Two examples of the suffix Old apprearing:-

TableA.EDBIdx
TableA.EDBTbl
TableA.EDBIdx.Old

EDBDatabase.EDBCat
EDBDatabase.EDBLck
EDBDatabase.EDBCat.Old

What is the meaning of the Old suffix?

I looked at the manager, File Extensions tab sheet. I can not see "Old"
listed.

Regards,
  Peter Evans

Peter


The .Old is like the .??k in DBISAM its a backup created when you make a change to the structure. Blow them away after your conversion has been successful.

Roy Lambert [Team Elevate]

On 26/07/2013 5:09 PM, Roy Lambert wrote:

>
> The .Old is like the .??k in DBISAM its a backup created when you make a change to the structure. Blow them away after your conversion has been successful.
>
> Roy Lambert [Team Elevate]
>

Thank you for that reply Roy. I thought that would be the reason.

The problem is that I did one Migrate. I would not have expected that I
would end up with .Old in that situation.

This will be a big problem. Why?
When my customers use the Migrate utility they will be left with .Old
files. This is a problem because my backup utility backups everything in
the folder. (I have other files in that folder.) Thus it will be backing
up unnecessary files and making the backup larger than necessary.

What I need is a Migrate utility that allows the deletion of .Old files.

If I don't have this I am going to have to write a utility for my
customers to run.

It is a bit complicated as I actually have to look in various folders to
delete the .Old files.

It would be simpler if the Migrate utility deletes them automatically.

So I want to make a request that the Migrate utility deletes them
automatically.

Regards,
  Peter Evans

Peter

>This will be a big problem. Why?
>When my customers use the Migrate utility they will be left with .Old
>files. This is a problem because my backup utility backups everything in
>the folder. (I have other files in that folder.) Thus it will be backing
>up unnecessary files and making the backup larger than necessary.

Its only really a problem if you give them a copy of EDBManager to do the migration, if you do it in code its easy to clean up after it.

>What I need is a Migrate utility that allows the deletion of .Old files.

>If I don't have this I am going to have to write a utility for my
>customers to run.

That sounds like you are supplying EDBManager to your customers - that's a bad idea simply because it has massive capabilities to mess up your database.

>It is a bit complicated as I actually have to look in various folders to
>delete the .Old files.

This is what I used for one of my conversions


procedure TForm1.FilesToDelete(ACurDir, fnMask: string);
var
SearchRec: TSearchRec;
iRet: Integer;
Cntr: integer;
begin
glProgress1.Caption := 'Deleting unwanted files .. [%d%%]';
glProgress1.Percent := 0;
Cntr := 0;
if ACurDir[Length(ACurDir)] <> '\' then ACurDir := ACurDir + '\';
iRet := FindFirst(ACurDir + fnMask, faAnyFile, SearchRec);
while iRet = 0 do begin
 if (SearchRec.Name <> '.') and (SearchRec.Name <> '..') then begin
  inc(Cntr);
  glProgress1.Percent := Min(100, Cntr);
  glProgress1.Update;
  DeleteFile(ACurDir + SearchRec.Name);
 end;
 iRet := FindNext(SearchRec);
end;
FindClose(SearchRec);
end;

called via

    Memo1.Lines.Add('Deleting old DBISAM tables');
    Memo1.Update;
    TranSesh.Close;
    FilesToDelete(TfRLive, '*.old');
    FilesToDelete(TfRLive, '*.dat');
    FilesToDelete(TfRLive, '*.idx');
    FilesToDelete(TfRLive, '*.blb');
    FilesToDelete(TfRLive, '*.dbk');
    FilesToDelete(TfRLive, '*.idk');
    FilesToDelete(TfRLive, '*.ibk');
    FilesToDelete(TfRLive, '*.bbk');
    FilesToDelete(TfRLive, '*.lck');


>It would be simpler if the Migrate utility deletes them automatically.

It would, but not being certain exactly where and why I'd prefer to have to make the choice to zap them myself.

If you want the migrator to do it for you the source is available so you could modify it to suite your needs.

I'd suggest in the EDBMigratorModuleDestroy procedure

Roy Lambert [Team Elevate]

Hi Roy

Have I got it all wonky in my mind, then?

I thought that the (EDB) .Old files were created before any change was
made to a table/index, including data changes.  Looking at my
timestamps it seems that the .Old (probably a temp) is created when a
table is opened - I guess that if the table is closed without change,
the temp is dropped otherwise it will replace the previous .Old

The migration presumably creates the tables/indexes, then makes the
..Old, then populates with migrated data.

Peter is concerned that the migration created .Old files and that his
routine backups will include all those .Old files.  But thereafter the
..Old files will be re-created in normal use so if he wants to exclude
them from his regular backups, will he not have to add a filter
(exclude *.Old) to his backup script?

I don't fancy deleting them in his application's shutdown code unless
he can be sure it is in single-user mode.

I think the .Old files are a useful safely net to have, even though I
have not had cause to revert <touching wood>.

Malcolm

Malcolm


>Have I got it all wonky in my mind, then?

From the rest of the post I think your assumption here is correct

ElevateDB simply appends the ".Old" to the existing file when creating backup copies during the optimization, alteration, or repair of tables.

I searched my stored ngs here and if you're the same Malcom I found your thread from 2009 so I can see where you're getting the ideas from
I also found my moans about the .olds from 2008 <vbg>

There are a number of unanswered questions from back then eg .

- Olds being created when you create an in-memory table and how to get rid of them.
- a request for a NOBACKUPS flag which is probably still in Tim's heap of things to be done (there was mention of it appearing in 2.04)

>I thought that the (EDB) .Old files were created before any change was
>made to a table/index, including data changes. Looking at my
>timestamps it seems that the .Old (probably a temp) is created when a
>table is opened - I guess that if the table is closed without change,
>the temp is dropped otherwise it will replace the previous .Old

See above

>The migration presumably creates the tables/indexes, then makes the
>.Old, then populates with migrated data.

I'd have to work though Tim's code to determine just when.

>Peter is concerned that the migration created .Old files and that his
>routine backups will include all those .Old files. But thereafter the
>.Old files will be re-created in normal use so if he wants to exclude
>them from his regular backups, will he not have to add a filter
>(exclude *.Old) to his backup script?

Yes if a table is altered, optimised or repaired.

>I don't fancy deleting them in his application's shutdown code unless
>he can be sure it is in single-user mode.

That's why I suggested the OnDestroy event of the migrator - that has to be single user

>I think the .Old files are a useful safely net to have, even though I
>have not had cause to revert <touching wood>.

Agreed. I have code in place to remove them when a table has been optimised or repaired. If things crash during the operation I can recover them.

Roy Lambert

Peter


There's a nice post from Adam Brett in the general ng giving code for a JOB to help with this. You could build it into your app.

The subject is ".Old files and how to clear them?"

Roy Lambert [Team Elevate]

On 28/07/2013 10:55 PM, Roy Lambert wrote:

>
> The subject is ".Old files and how to clear them?"

I will look into that post too. Thank you.

Regards,
  Peter Evans

Peter,

<< What is the meaning of the Old suffix? >>

..Old files are copies of files made for backup purposes before the file is
altered due to structural changes.  It occurs during migrations because
indexes are created as part of the migration.

Tim Young
Elevate Software
www.elevatesoft.com

Peter,

<< When my customers use the Migrate utility they will be left with .Old
files. This is a problem because my backup utility backups everything in the
folder. (I have other files in that folder.)  >>

I wouldn't backup an ElevateDB database using an external utility unless
you're 100% sure that the database isn't being used when the backup occurs.
The normal recommendation is to use the ElevateDB BACKUP DATABASE statement
to backup the database, and then use your external utility to backup the
..edbbkp file created by the native EDB backup.

Tim Young
Elevate Software
www.elevatesoft.com