lucasdebeltran wrote:Mr. Nages,
Thank you very much.
About using logical fields, I do for example:
if oRs:Fields( "PRESTA" ):Value = .T.
[..]
But you advise me to use 1 or 0 for logicals as to work with Oracle.
But if I change .t. to 1 I get an error.
Thank you very much.
Mr Lucas
You are right.
Here our aim to use the same code for all RDBMSs fails.
We can use BIT fieldtype in MSACCESS, SQLSERVER, MYSQL, SQLITE3 ( probably POSTGRE SQL which has a Boolean field type ). ADO recognizes BIT fields as adBoolean type. Value of this field is read as .T. or .F., though actually the data stored in the database table is 1 or 0.
We can use expressions like "if oRs:Fields(n):Value" or "if oRs:fields(n):Value == .t.". etc.
While assigning value to these fields in ADO, we can assign either a logical value ( .T. of .F. ) or a numeric value ( 1 or 0 ). Both work.
But with Oracle and Firebird, we have no choice but to use either NUMBER/NUMERIC(1) or CHAR(1). For obvious reasons we prefer NUMBER(1) with values 1 or 0.
ADO reads them as numeric values only and not logical values. We can not use these field values like logical values for comparisons.
Only compatible way appears to be
if Empty( oRs:Fields( "booleanfield" ):Value ) or ! Empty( ... )
But this usage is ugly and not intutively clear.
In my personal case, I always use Wrapper classes which take care of the difference between oracle and others. So I use them like normal logical fields.
As far as assignment goes, assigning 1 or 0 (even in ADO) works uniformly with all databases.
Here, Mr. EMG's approach is worth mentioning. If we see his code for creation of tables, he uses INT for logical values. ( we can change it as NUMBER(1) for Oracle)
Using this approach we never deal with Logical values in our ADO code and instead we compare the field value with 1 or 0.