Hi all,

DBISAM v4, D6

I am working on a versioning system for my application. I have some
code that when the application starts it:
- checks if the table exists, & if not, creates it
- then checks the userMajorVersion & userMinorVersion and adds Fields
if need be.

It all works OK on my little test application of 1 table. In my REAL
application, comprising 180 tables, I am trying to figure out the best
way to set it up. If I place the VersionChecking in the OnCreate of my
Main Form that means every time the users run it, it is going to check
180 tables (if the data folder is on a file server, the time delay is
going to be a pain). Same thing when the user changes to a different
DATA folder while the application is running.

What do you think is a 'smart way' of implementing VersionChecking?
- having the last Version Number in a .ini file, and if the Version
Number stored in the .exe file is different, run the VersionChecking
routine then?

or just bite-the-bullet and have a splash screen with a progress bar
indicating that VersionChecking is taking place?

or if the application gives an error of 'missing table field', tell
the user to run the VersionChecker routine? to do this I guess I have
to trap the error message somewhere central so I do not have to
rewrite all my forms to trap it.

Any other suggestions? Many thanks.

Regards,
Pat

Pat,

we implemented versioning using Tim's Reverse Engineering function in DBSYS.
It is very handy and easy to implement version checking by code and without
external data in .ini file. Only the first user checks table versions and
all next users skip this function because exclusive table use is needed.

Here is code snippet we use for version checking:
----
   with TableToCreate do begin
     DatabaseName := baza.databaseName;
     sessionName  := baza.sessionName;
     TableName := 'panorama';
     Exclusive := True;
     if (not Exists) then begin
       with FieldDefs do begin
         Clear;
         Add('ident', ftAutoInc, 0, False, '', '', '', '', fcNoChange, 0);
         Add('razred', ftInteger, 0, False, '', '', '', '', fcNoChange, 0);
         Add('nadrejen', ftInteger, 0, False, '', '', '', '', fcNoChange,
0);
         Add('naziv', ftString, 35, False, '', '', '', '', fcNoChange, 0);
         Add('koncen', ftBoolean, 0, False, '', '', '', '', fcNoChange, 0);
         Add('trenutek', ftDateTime, 0, False, '', '', '', '', fcNoChange,
0);
         Add('lastnik', ftInteger, 0, False, '', '', '', '', fcNoChange,
0);
         Add('origId', ftInteger, 0, False, '', '', '', '', fcNoChange, 0);
         Add('refAzur', ftBoolean, 0, False, 'true', '', '', '',
fcNoChange, 0);
         Add('jeDistrib', ftBoolean, 0, False, 'true', '', '', '',
fcNoChange, 0);
         Add('polja', ftMemo, 0, False, '', '', '', '', fcNoChange, 0);
         Add('komentar', ftBlob, 0, False, '', '', '', '', fcNoChange, 0);
       end;
       with IndexDefs do begin
         Clear;
         Add('', 'ident', [ixPrimary, ixUnique], '', icNone);
         Add('podrejeni', 'nadrejen;naziv', [], '', icTrailingByte);
         Add('nazivi', 'naziv', [], '', icFull);
       end;
       CreateTable(vstopPar.localeID, 1, 2, False, '',
                  'objekti panorame', 4096, 128, 0, '',
                   StopWords, spaceChars, includeChars);
     end;
     if ((userMajorVersion = 1) and (userMinorVersion = 0)) then begin
       FieldDefs.Update;
       IndexDefs.update;
       if FieldDefs.IndexOf('refAzur') < 0 then
         FieldDefs.Insert(8, 'refAzur', ftBoolean, 0, False, 'true', '',
'', '', fcNoChange);
       if FieldDefs.IndexOf('jeDistrib') < 0 then
         FieldDefs.Insert(9, 'jeDistrib', ftBoolean, 0, False, 'true', '',
'', '', fcNoChange);
       alterTable(vstopPar.localeID, 1, 1, False, '',
                  'objekti panorame', 4096, 128, -1, '',
                   StopWords, spaceChars, includeChars);
     end;
     if ((userMajorVersion = 1) and (userMinorVersion = 1)) then begin
       FieldDefs.Update;
       IndexDefs.update;
       IndexDefs.Add('nazivi', 'naziv', [], '', icFull);
       alterTable(vstopPar.localeID, 1, 2, False, '',
                  'objekti panorame', 4096, 128, -1, '',
                   StopWords, spaceChars, includeChars);
     end;
     FieldDefs.Update;
     IndexDefs.update;
  end;
---

If user wants to use the files from an old archive then this function
converts all data to newest data structure regardless of archive age and
table structures in it. If there is no pareticular table in database then
the new one with newest data strusture is created otherwise only table
version is checked. The vesrion check is very fast if there is no need to
table restructure.

Regards
Iztok Lajovic
KreS, Kreativni sistemi, d.o.o.

"Pat" <pat@downunder.com> wrote in message
news:au6ni49361uede5ssokm1sk0s31f80157s@4ax.com...
> Hi all,
>
> DBISAM v4, D6
>
> I am working on a versioning system for my application. I have some
> code that when the application starts it:
> - checks if the table exists, & if not, creates it
> - then checks the userMajorVersion & userMinorVersion and adds Fields
> if need be.
>

I  test the user minor version in just one table. This tells me if I need to
apply an upgrade, which could be for ANY table(s). I release the upgrades as
SQL scripts, with a predefined name (UPGRADEnn.SQL where nn is the minor
version number).

I decided that I did not need to test each individual table. If for example
UPGRADE03.SQL upgrades tables 5, 7 and 13, I can still look at the user
minor version of Table1 (my control table), if it is 2 then I know that I
have to apply UPGRADE03. IOW, the upgrades are at the application, not the
individual table, level. Arbitrarily, I keep the current version on Table1
(could have selected any other table). But I only need to test one talbe to
determine if I need ANY database upgrade. Of course every upgrade changes
the user minor version of table 1.

> It all works OK on my little test application of 1 table. In my REAL
> application, comprising 180 tables, I am trying to figure out the best
> way to set it up. If I place the VersionChecking in the OnCreate of my

Put it in the datamodule, execute after you initialize the database
component.

>
> What do you think is a 'smart way' of implementing VersionChecking?
> - having the last Version Number in a .ini file, and if the Version
> Number stored in the .exe file is different, run the VersionChecking
> routine then?

How about a constant in the datamodule?

>
> or just bite-the-bullet and have a splash screen with a progress bar
> indicating that VersionChecking is taking place?
>
> or if the application gives an error of 'missing table field', tell

Nah. In my scenario, if I want for whatever reason (and there are many valid
reasons) to run the upgrade as a separate program, I test the user minor
version of table1 against the constant in the datamodule, if they are not
equal I show an appropriate message and exit the program.

Robert

Hi Iztok,

Thanks for the code snippet and idea  

Pat

Hi Robert,

>> I am working on a versioning system for my application. I have some
>> code that when the application starts it:
>> - checks if the table exists, & if not, creates it
>> - then checks the userMajorVersion & userMinorVersion and adds Fields
>> if need be.
>>
>
>I  test the user minor version in just one table. This tells me if I need to
>apply an upgrade, which could be for ANY table(s). I release the upgrades as
>SQL scripts, with a predefined name (UPGRADEnn.SQL where nn is the minor
>version number).
>
>I decided that I did not need to test each individual table. If for example
>UPGRADE03.SQL upgrades tables 5, 7 and 13, I can still look at the user
>minor version of Table1 (my control table), if it is 2 then I know that I
>have to apply UPGRADE03. IOW, the upgrades are at the application, not the
>individual table, level. Arbitrarily, I keep the current version on Table1
>(could have selected any other table). But I only need to test one talbe to
>determine if I need ANY database upgrade. Of course every upgrade changes
>the user minor version of table 1.

Great idea of having just one table as the version 'reference'. If I
store the current table build no. on my main form (say it is 3) that
led me on to think of something like, on startup,:

- if .exe variable = 3 and table version = 2, tell user to upgrade the
data folder
- if .exe variable = 3 and table version = 4, tell user to upgrade the
program (needed in multi terminal sites)
- if .exe variable = 3 and table version = 3, everybody should be
happy

>> It all works OK on my little test application of 1 table. In my REAL
>> application, comprising 180 tables, I am trying to figure out the best
>> way to set it up. If I place the VersionChecking in the OnCreate of my
>
>Put it in the datamodule, execute after you initialize the database
>component.

I will try the datamodule approach on my little test app first.

Thanks Robert!

Pat

Pat wrote:
> >
> > Put it in the datamodule, execute after you initialize the database
> > component.
>
> I will try the datamodule approach on my little test app first.
>
> Thanks Robert!
>
> Pat

Hi Pat

I use a method almost identical to Robert's with no problems.  The way
I differ is that I don't use UPGRADExx.SQL files, but do it in hard
code in my VersionUp module.  My application's database version number
is kept in Project>>Options>>VersionInfo.

The reason I prefer to hard code it is that often the database change
is not just creation/alteration of tables, but requires some logical
change too - and while most stuff can be done in SQL, a direct Delphi
approach is sometimes a lot easier.  Also I only need to ship the .exe.

Cheers

Jeff


--
Jeff Cook
Aspect Systems Ltd
www.aspect.co.nz
+
Joan and Jeff Cook
The Cooks Oasis
www.cookislandsoasis.com

Hi Jeff,

>I use a method almost identical to Robert's with no problems.  The way
>I differ is that I don't use UPGRADExx.SQL files, but do it in hard
>code in my VersionUp module.  My application's database version number
>is kept in Project>>Options>>VersionInfo.
>
>The reason I prefer to hard code it is that often the database change
>is not just creation/alteration of tables, but requires some logical
>change too - and while most stuff can be done in SQL, a direct Delphi
>approach is sometimes a lot easier.  Also I only need to ship the .exe.

thanks for the tips  

Pat