Alex, thanks 4 your response!
I understand what you wrote, but I think this is not related to my problem.
Yogi suggested to resync the def with table data, on admin interface, and it was a correct suggestion.
It worked correctly. Now the type of my Add_Date, Mod_Date, Expire_Date are reported correctly as 'DATETIME'.
I assume the original problem as solved.
Yes, I already found Type.pm earlier, and that calmed me down a bit.
Just a last question:
If Yogi is right, then def files are always resync-ed when table data is changed through admin interface.
I hope, that resync is always done, when GT::SQL::Creator is used. Is that true?
Best regards,
Webmaster33
Paid Support from Webmaster33. Expert in Perl programming & Gossamer Threads applications. (click here for prices)
Webmaster33's products (upd.2004.09.26) | Private message | Contact me | Was my post helpful? Donate my help...
Quote:
This is the proper behavior, as otherwise you run into problems because Oracle calls an INT a NUMBER, and it calls a TEXT field a CLOB. The point of the def file is to provide a common interface so you can work on a TEXT field and not worry about the differences between Oracle or MS SQL.Yogi suggested to resync the def with table data, on admin interface, and it was a correct suggestion.
It worked correctly. Now the type of my Add_Date, Mod_Date, Expire_Date are reported correctly as 'DATETIME'.
I assume the original problem as solved.
Quote:
Look at GT/SQL/Type.pm to see a list of types GT::SQL supports.Just a last question:
If Yogi is right, then def files are always resync-ed when table data is changed through admin interface.
I hope, that resync is always done, when GT::SQL::Creator is used. Is that true?
Best regards,
Webmaster33
Paid Support from Webmaster33. Expert in Perl programming & Gossamer Threads applications. (click here for prices)
Webmaster33's products (upd.2004.09.26) | Private message | Contact me | Was my post helpful? Donate my help...