Strange C++ VSDK2 anomaly when creating DB Table

[Ruslan Zasukhin]

On 6/20/06 6:30 AM, "Matthew Jew" <mjew at icnc.com> wrote:

Hi Matthew, 
 
> I am experiencing a strange anomaly when creating a DB table using
> the C++ VSDK2.
> 
> When I create the table using this sequence:
> 
> void TblAuthFailureLog::Create( I_Database_Ptr DB )
> {
> Table   = DB->CreateTable  ( "AuthFailureLog" );
> customerNumber  = CreateULongField  ( Table, "customerNumber" );
> clientIP   = CreateULongField  ( Table, "clientIP" );
> serverIP   = CreateULongField  ( Table, "serverIP" );
> loginDateTime = CreateDateTimeField  ( Table, "loginDateTime" );
> username  = CreateVarCharField  ( Table, "username", 32 );
> password  = CreateVarCharField  ( Table, "password", 32 );
> Table->Flush();
> }
> 
> Then the password field is created incorrectly, with a max length of
> 0 instead of 32.
> The diagnose function of VStudio reports this:
> ==========> Field: password , type VarChar
> .....> VarCharFile
> Length of varchar value at record 1 is = 14 but maximal length of
> this VarChar is = 0
> ...........Page 1
> 
> Problems found!  ( VarCharFile )
> 
> 
> Problems found!  ( Field: password , type VarChar )
> 
> However, if I just change the order in which the fields are created,
> thusly:
> 
> void TblAuthFailureLog::Create( I_Database_Ptr DB )
> {
> Table   = DB->CreateTable  ( "AuthFailureLog" );
> customerNumber  = CreateULongField  ( Table, "customerNumber" );
> loginDateTime = CreateDateTimeField  ( Table, "loginDateTime" );
> username  = CreateVarCharField  ( Table, "username", 32 );
> password  = CreateVarCharField  ( Table, "password", 32 );
> clientIP   = CreateULongField  ( Table, "clientIP" );
> serverIP   = CreateULongField  ( Table, "serverIP" );
> Table->Flush();
> }
> 
> so that the password field is NOT created last, then everything works
> fine.
> 
> I have saved copies of these databases, if you want to look at them.
> 
> (Ruslan, this is the same project you have looked at for me. It seems
> to work now, except for this anomaly.)

Well, I think reason can be in db->Flush() although looks strange.
We have not see never such glitches...

Although if you do db->Close() then db.flush must be done self.
If this is reproducible please send to me or may be better add as report to
Mantis and attach there files (without serial numbers :-)

-- 
Best regards,

Ruslan Zasukhin
VP Engineering and New Technology
Paradigma Software, Inc

Valentina - Joining Worlds of Information
http://www.paradigmasoft.com

[I feel the need: the need for speed]