Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM General » View Thread |
Messages 1 to 6 of 6 total |
Changing 2 field lengths in a table, ERROR #10000 |
Mon, Nov 3 2008 8:19 PM | Permanent Link |
Joel Schaubert | I have some new code that attempts to raise the limit of 2 strings up from their current limit of 70 characters. The code is working fine when I just adjust one field, but when I do two fields like this, OptionsTable->Exclusive = true; OptionsTable->RestructureFieldDefs->Update(); OptionsTable->RestructureFieldDefs->Delete(1); OptionsTable->RestructureFieldDefs->Insert(1,25,"IMPFILENAM",ftString,250,false,"","","",""); OptionsTable->RestructureFieldDefs->Delete(12); OptionsTable->RestructureFieldDefs->Insert(12,25,"TEMPDIR",ftString,250,false,"","","",""); OptionsTable->RestructureTable(0,0,1,2,false,"","Options table",512,false); OptionsTable->Close(); OptionsTable->Exclusive = false; then I get an error like this Error # 10000 Invalid field definition speicified for the field 'IMPFILENAME' Strange since deleting these 2 lines OptionsTable->RestructureFieldDefs->Delete(12); OptionsTable->RestructureFieldDefs->Insert(12,25,"TEMPDIR",ftString,250,false,"","","",""); allows the size of the IMPFILENAME Field to be adjusted just fine. Why does adding a second alteration cause an error regarding the first altered field? Joel |
Tue, Nov 4 2008 11:11 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Joel,
<< Why does adding a second alteration cause an error regarding the first altered field? >> You need to make sure that you assign a unique field # (second parameter) when you use the Insert method: OptionsTable->RestructureFieldDefs->Insert(1,25,"IMPFILENAM",ftString,250,false,"","","",""); OptionsTable->RestructureFieldDefs->Delete(12); OptionsTable->RestructureFieldDefs->Insert(12,25,"TEMPDIR",ftString,250,false,"","","",""); OptionsTable->RestructureTable(0,0,1,2,false,"","Options table",512,false); You're inserting two field defs with the same field # (25). The first parameter is the index (0-based) into the field defs list, while the second parameter is the logical field # (1-based). The field # for new fields should be the next field # based upon the total number of fields in the table. -- Tim Young Elevate Software www.elevatesoft.com |
Tue, Nov 4 2008 12:01 PM | Permanent Link |
Joel Schaubert | You need to make sure that you assign a unique field # (second parameter)
when you use the Insert method: OptionsTable->RestructureFieldDefs->Insert(1,25,"IMPFILENAM",ftString,250,false,"","","",""); OptionsTable->RestructureFieldDefs->Delete(12); OptionsTable->RestructureFieldDefs->Insert(12,25,"TEMPDIR",ftString,250,false,"","","",""); OptionsTable->RestructureTable(0,0,1,2,false,"","Options table",512,false); You're inserting two field defs with the same field # (25). The first parameter is the index (0-based) into the field defs list, while the second parameter is the logical field # (1-based). The field # for new fields should be the next field # based upon the total number of fields in the table. -------------- Ok so by trial and error I came up with this which seems to work. Checking before and after with dbsys tool it has given me the schema changes that were desired. OptionsTable->Exclusive = true; OptionsTable->RestructureFieldDefs->Update(); OptionsTable->RestructureFieldDefs->Delete(1); OptionsTable->RestructureFieldDefs->Insert(1,26,"IMPFILENAM",ftString,250,false,"","","",""); OptionsTable->RestructureFieldDefs->Delete(12); OptionsTable->RestructureFieldDefs->Insert(12,25,"TEMPDIR",ftString,250,false,"","","",""); OptionsTable->RestructureTable(0,0,1,2,false,"","Options table",512,false); OptionsTable->Close(); So I originally had 24 fields in the table. If I delete 1, then insert 1, then delete 1, and insert 1, why wouldn't that last parameter be 24 for both cases? Joel |
Tue, Nov 4 2008 3:56 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Joel,
<< So I originally had 24 fields in the table. If I delete 1, then insert 1, then delete 1, and insert 1, why wouldn't that last parameter be 24 for both cases? >> The field numbers are used to determine whether a field definition is new or whether it is an existing field definition. Using 24 would make DBISAM think that each new field definition was a restructure of the existing field #24. Using field numbers allow field names to be changed without losing data. -- Tim Young Elevate Software www.elevatesoft.com |
Wed, Nov 5 2008 2:04 PM | Permanent Link |
Joel Schaubert | Let me say that as a new user to DBISAM, I am really surprised with how active and helpful the boards are for this project. The help on these boards exceeds what I have experienced for any other software I have used. >>Using field numbers allow field names to be changed without losing >>data. AHA ! That is some great functionality. After changing my code to reuse the same field numbers like this OptionsTable->RestructureFieldDefs->Delete(1); OptionsTable->RestructureFieldDefs->Insert(1,2,"IMPFILENAM",ftString,250,false,"","","",""); OptionsTable->RestructureFieldDefs->Delete(12); OptionsTable->RestructureFieldDefs->Insert(12,13,"TEMPDIR",ftString,250,false,"","","",""); OptionsTable->RestructureTable(0,0,1,2,false,"","Options table",512,false); It does indeed preserve the very data itself. This is a GREAT functionality. I would suggested adding it to the documentation. On this page http://www.elevatesoft.com/manual?action=mantopic&id=dbisam4&product=r&version=2007&category=1&topic=15 You could add something like this. If you wanted to alter the table changing the CustomerName field from 30 character to 60 but still preserve all the existing data in the current CustomerName columns, you could delete the existing defintion, and reinsert the new defintion into the same field number like this FieldDefs.Delete(1); FieldDefs.Insert(1,2,'CustomerName',ftString,60,False); After this operation the table structure would be .... with all of the original data in the CustomerName present in altered table 2 CustomerName ftString 30 |
Wed, Nov 5 2008 3:39 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Joel,
<< This is a GREAT functionality. I would suggested adding it to the documentation. On this page http://www.elevatesoft.com/manual?action=mantopic&id=dbisam4&product=r&version=2007&category=1&topic=15>>On that same page:"The reason for this difference is that DBISAM uses field numbers (1-based)to distinguish between existing fields in a table and new fields beingadded. It also uses field numbers in addition to the index position(0-based) of a field definition in the FieldDefs property to determine if afield has been moved in the structure, but still exists. The use of fieldnumbers also allows for the renaming of existing fields in a table withoutlosing data when altering the structure of an existing table."I'll consider adding the more specific text that you cite, however.--Tim YoungElevate Softwarewww.elevatesoft.com |
This web page was last updated on Saturday, May 4, 2024 at 12:54 AM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |