Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM General » View Thread |
Messages 1 to 7 of 7 total |
Implementing table version checking |
Tue, Nov 25 2008 1:38 AM | Permanent Link |
Pat | 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 |
Tue, Nov 25 2008 4:07 AM | Permanent Link |
"Iztok Lajovic" | 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. |
Tue, Nov 25 2008 9:38 AM | Permanent Link |
"Robert" | "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 |
Wed, Nov 26 2008 12:38 AM | Permanent Link |
Pat | Hi Iztok,
Thanks for the code snippet and idea Pat |
Wed, Nov 26 2008 12:52 AM | Permanent Link |
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 |
Fri, Nov 28 2008 2:55 PM | Permanent Link |
"Jeff Cook" | 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 |
Fri, Nov 28 2008 6:44 PM | Permanent Link |
Pat | 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 |
This web page was last updated on Saturday, April 27, 2024 at 08:52 PM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |