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

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

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

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

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

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