Ben,

Are you sure you have the latest version? I had similar problems and the site had several versions of 6.03c (with different dates) before the problems went away. The current version is dated 4/30/02.


>Hi,
>
>We have notice a problem while using the Update method of SDTMgr. Here is an example :
>
>We have a table with 3 fields : id_husyt c(9), code_typas_inte1 c(10), code_typas_inte2 c(10)
>
>We then modified the table structure like that : id_husyt c(9), code_typas_depar c(10), code_typas_inte1 c(10), code_typas_inte2 c(10), code_typas_inte3 c(10)
>
>We used the method Update of SDTMgr to get the job done. The app starts and checks if there is a need for an update, if so it calls the update method and here is the result:
>
>The data has moved from the field 'code_typas_inte1' to the field 'code_typas_depar' which is one of the new field with no data yet !
>
>We looked into the source code and figured out that Stonefield copies the fields to a table wich accepts only 10 car long field names, thus the problem. code_typas_inte1 becomes code_typa1 and code_typas_inte2 becomes code_typa2. When "reconverting" back to long field names where we inserted the new field code_typas_depar, this field gets the data from code_typa1, code_typas_inte1 gets data from code_typa2 and code_typas_inte2 get blank/Default values.
>
>To "bypass"¨ this problem, the solution is to append the new fields at the end of the structure, not to insert them. If one is not aware of this it could cause major havoc in an update scheme where converting data to a new structure !
>
>-Ben