Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM General » View Thread |
Messages 1 to 6 of 6 total |
Automated Restructuring of Installed databases |
Tue, Oct 22 2013 11:36 PM | Permanent Link |
Neil Huhta | Hello All:
I need to automate the running of processes that restructure the data within a DBISAM database - I have a concept and am seeking comments - I am using version 1.21 which is file server only I have an awesome table restructuring tool which I use now - it compares the client database structure (fields, indexes) to what the client has and makes the appropriate changes.It works great. What I am talking about doing now - is adding a process that needs to be run 1 time - that actually modifies the customers data - for instance - a Tax parameter was Y,N for Yes/No - It is changed to Y,S,N Y=Tax Products together with other products S=Tax product seperately by itself N=NoTax So - each customer upgrading to build 455 or later of my app - needs to run this tax conversion routine 1 time only I need to figure out a very reliable way for making thid happen I was thinking of doing the following 1) Add a table to track restructure processes - call it the Restruct Table 2) When an update is run - the updater would check the restruct Table - if "TaxUpdate1" is not listed then the "TaxUpdate1" process would be run and then the "TaxUpdate1" would be added to the Restruct table A) What if this table is corrupted - should i run an indexx repair before checking it ??? B) Is it worth adding a version checking mechanism as a double check .. ie "If Oldversion<455 and "TaxUpdate1" not found then run "TaxUpdate1" C) before running the TaxUpdate1 the app will create a subfolder TaxUpdate1 and copy all of the affected files (pre-update) into it - is it worth checking for the existence of folder "TaxUpdate1" as a 3rd check ??? Obviously I am concerned about data integrity - during the update I have exclusive access to the data Thank you for your thoughts PS - Once I run a few updates I will be switching to ElevateDB Neil Huhta |
Wed, Oct 23 2013 2:55 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Neil
I don't remember that far back. Does V1 have a table version that you could use to check? If so use that rather than an external table since it removes the need for 2 A & B 2C is an interesting point and my take would be yes from a view of if its done don't duplicate BUT someone can always come along in Windows and delete the directory so don't rely on it. The other alternative which means more work on your side is to change the name of the field - easy to check then. Can you change your name - I don't thing you are really news.elevatesoft.com Roy Lambert [Team Elevate] |
Thu, Oct 24 2013 12:35 AM | Permanent Link |
Neil Huhta | Roy:
Version 1 has table versions - I could use that - but I am ver hesitant. The reason I want to use a table is because in addition to restructuringthe table, I need to modify data such as changing the primary key, or changing the key that links a master/detail set of tables, etc. This table lets me know that 1) the re-organization of the data has run 2) I have 10-15 of these re-organizations to roll out - too complex to manage by version number alone I just tried to change my name - thank you. My V1 app is awesome - but very fat client - I am looking forward to playing with ElevateDB - it will be a significant re-write plus old code cleanup. Neil "Roy Lambert" <roy@lybster.me.uk> wrote in message news:3B399BB0-F44A-4444-9F79-14EC406FD78E@news.elevatesoft.com... > Neil > > > I don't remember that far back. Does V1 have a table version that you > could use to check? If so use that rather than an external table since it > removes the need for 2 A & B > > 2C is an interesting point and my take would be yes from a view of if its > done don't duplicate BUT someone can always come along in Windows and > delete the directory so don't rely on it. > > The other alternative which means more work on your side is to change the > name of the field - easy to check then. > > Can you change your name - I don't thing you are really > news.elevatesoft.com > > Roy Lambert [Team Elevate] > |
Thu, Oct 24 2013 2:46 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Huhtaman
>but very fat client Show you be speaking of the people who pay you money in that manner? Roy |
Thu, Oct 24 2013 3:36 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | That doesn't work with the typo - I'll try again
>but very fat client Should you be speaking of the people who pay you money in that manner? Roy |
Thu, Oct 24 2013 7:30 AM | Permanent Link |
Matthew Jones | > The reason I want to use a table is because in addition to
> restructuringthe table, I need to modify data such as changing the > primary key, or changing the key that links a master/detail set of > tables, etc. What I've always done is actually just check for the keys and fields that are needed, and alter as appropriate. I'd never change the primary index on old tables - a new index would be just fine so why bother. I've included the field check code below. Obviously any data conversion actually needs to be done too. /Matthew Jones/ tableChecker := TDBISAMTable.Create(nil); try tableChecker.SessionName := g_xThreadSession.SessionName; tableChecker.DatabaseName := szDatabaseLocation; CheckFieldPresent(tableChecker, 'MyTable.dat', 'apQuestionID', ftLargeint, 0); ... procedure TMyObject.CheckFieldPresent(tableChecker: TDBISAMTable; szDbName: string; szFieldName: string; ftType: TFieldType; nFieldLength: Integer); var nLoop: Integer; nIndex: Integer; begin tableChecker.Active := False; tableChecker.TableName := szDbName; tableChecker.IndexDefs.Update; tableChecker.FieldDefs.Updated := False; tableChecker.FieldDefs.Update; nIndex := -1; for nLoop := 0 to (tableChecker.FieldDefs.Count - 1) do begin // CodeSite.SendMsg('Field ' + IntToStr(nLoop) + ' = ' + TableLog.FieldDefs[nLoop] ..Name); if 0 = AnsiCompareText(tableChecker.FieldDefs[nLoop].Name, szFieldName) then begin nIndex := nLoop; break; end; end; if nIndex > 0 then begin if (tableChecker.FieldDefs[nLoop].DataType <> ftType) or (tableChecker.FieldDefs[nLoop].Size <> nFieldLength) then begin tableChecker.FieldDefs[nLoop].DataType := ftType; tableChecker.FieldDefs[nLoop].Size := nFieldLength; Report('Database schema change: ' + szFieldName + '/' + IntToStr(nFieldLength)); tableChecker.AlterTable(0, 0, 2, true, StringLength, 'DatabaseFile', 1024, 1024); // ENCRYPTING end; end else begin tableChecker.FieldDefs.Add(szFieldName, ftType, nFieldLength, False, '', '', '', ''); Report('Database schema update: ' + szFieldName + '/' + IntToStr(nFieldLength)); tableChecker.AlterTable(0, 0, 2, true, StringLength, 'DatabaseFile', 1024, 1024); // ENCRYPTING end; end; |
This web page was last updated on Wednesday, April 24, 2024 at 11:07 AM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |