With the old database API, DatabaseField.Value returns a variant of the same type as the database table field. If the table has an integer column, the value will return an integer variant.
With database API2, DatabaseColumn.Value returns a string variant regardless of the type of data in the column.
As the documentation says, “Typically you should use the type-specific “Value” properties to get and set values from the database.” I agree, except if you have a method that takes a recordset, with the old API the method can figure out the data type of the columns. But now with RowSet, the method will find that all columns are String.
With the old database API, DatabaseField.Value returns a variant of the same type as the database table field. If the table has an integer column, the value will return an integer variant.
With database API2, DatabaseColumn.Value returns a string variant regardless of the type of data in the column.
As the documentation says, “Typically you should use the type-specific “Value” properties to get and set values from the database.” I agree, except if you have a method that takes a recordset, with the old API the method can figure out the data type of the columns. But now with RowSet, the method will find that all columns are String.[/quote]
That would be a huge issue for some generic DB handling code I have written if I had started using API 2!
The actual data type for the column is available in the FieldSchema. Assuming it from the Record/RowSet variant is an unreliable approach. You might consider updating this before making the move to API 2.
I do a lot of that paricualry using views created from multiple tables… being able to do that that is kind of the point of using a relational database.