DBISAM version 4 has done away with RestructureTable and replaced it with the AlterTable function. I am having trouble implementing the new function. I like to learn by example.
## Deliverables
Using the old RestructureTable function, I used something like the following ... procedure RestructureMagMedia; var ? ? TableToRestructure: TDBISAMTable; begin ? ? TableToRestructure:=[login to view URL](Application); ? ? try ? ? ? ? with TableToRestructure do begin ? ? ? ? ? ? DatabaseName := ggDatabaseName; ? ? ? ? ? ? TableName:='[login to view URL]'; ? ? ? ? ? ? Exclusive:=True; ? ? ? ? ? ? with RestructureFieldDefs do begin ? ? ? ? ? ? ? ? Clear; ? ? ? ? ? ? ? ? Add('uid',ftAutoInc,0,False,'','','','',fcNoChange,1); ? ? ? ? ? ? ? ? Add('authPerson',ftString,24,False,'','','','',fcNoChange,2); ? ? ? ? ? ? ? ? Add('fy_earned',ftDate,0,False,'','','','',fcNoChange,3); ? ? ? ? ? ? ? ? Add('fy_applies',ftDate,0,False,'','','','',fcNoChange,4); ? ? ? ? ? ? ? ? Add('gc_date',ftDate,0,False,'','','','',fcNoChange,5); ? ? ? ? ? ? ? ? Add('eAbn',ftString,13,False,'','','','',fcNoChange,6); ? ? ? ? ? ? ? ? Add('eBranchNumber',ftInteger,0,False,'','','','',fcNoChange,7); ? ? ? ? ? ? ? ? Add('eName',ftString,200,False,'','','','',fcNoChange,8); ? ? ? ? ? ? ? ? Add('eTradeAs',ftString,200,False,'','','','',fcNoChange,9); ? ? ? ? ? ? ? ? Add(etc ... ? ? ? ? ? end; ? ? ? ? ? ? with RestructureIndexDefs do begin ? ? ? ? ? ? ? ? Clear; ? ? ? ? ? ? ? ? Add('','uid',[ixPrimary,ixUnique],icNone); ? ? ? ? ? ? end; ? ? ? ? ? ? RestructureTable(0,0,0,0,True,MY_PASSWORD,'',64,-1,True); ? ? ? ? end; ? // with TableToRestructure ? ? finally ? ? ? ? [login to view URL]; ? ? end; end; ? // RestructureMagMedia When a table was initially opened, if the file structure had changed and exception would be generated, which would be caught and the above procedure would then be executed to update the structure. This worked well, because it did not matter how far behind in the upgrade process the user was, the above took care of them. With the new AlterTable, I do not seem to have the same flexibility. Let's say that ... ? FieldA was added in January 2004 FieldB was added in May 2004 FieldC was added in August 2004 Someone upgrading now may have last upgraded in March 2004, so they have FieldA, but they do not have the other 2 fields. We are upgrading hundreds of users who upgrade at different times. if I say ... [login to view URL](12,13,'FieldA',ftBCD,2,False); and the field already exists for this user, I have a problem. Even if I were able to check whether the field exists, that still means that I have to leave that checking code in there as long as there are users who may not have upgraded, which in some cases means that the code has to stay in there for years, as some users may not upgrade annually, even if they should. Can you see the problem? I need a working example that changes the structure of a table by: 1. Changing the field name of an existing record. 2. Adding a new field. 3. Adding a new index. I need it implemented in such a way the the routine can be run again, with not exception raised. This is necessary because in reality, the code has to serve many users, each at a different upgrade status (as outlined in the description).
## Platform
I am using Windows XP Delphi 7 DBISAM 4 ... that is the main thing.