Zeoslib Portal

aehimself wrote: ↑26.01.2022, 12:29 Now, I only need to "translate" these to understandable values... too bad I can not use GetColumnType as I don't have a resultset to have metadata for it

  TZSQLType = (stUnknown,
    //fixed size DataTypes first
    stBoolean,
    stByte, stShort, stWord, stSmall, stLongWord, stInteger, stULong, stLong, //ordinals
    stFloat, stDouble, {$IFDEF ZEOS90UP}stDecimal128,{$ENDIF} //floating types
    stCurrency, stBigDecimal, //ExactTypes
    stDate, stTime, stTimestamp,
    stGUID,
    //now varying size types in equal order
    stString, {should be used for raw strings only}
    stUnicodeString{should be used for national strings only}, stBytes,
    //EH: these 3 enums below should be used for real streamed data only (FB/PG(OIDLobs)/MySQL/ODBC/OleDB/Oracle)
    //otherwise stString...stBytes are sufficent (SQLite, Postgres Varchar/Text/byteea f.e.)
    //our RowAccassor eats all long data since i added the ptr ref/deref technic years ago
    //it's not worth it handling all obselete TDataSet incompatibilities on Dbc layer
    //that's a problem of component layer only
    stAsciiStream{should be used for raw streams only}, stUnicodeStream{should be used for unicode streams only}, stBinaryStream,
    {$IFDEF ZEOS90UP}
    stJSON, stXML, stVariant,
    {$ENDIF ZEOS90UP}
    //finally the object types
    stArray, stResultSet{$IFDEF ZEOS90UP}, stStatement{$ENDIF});

TypeName := GetEnumName(TypeInfo(Value), Ord(Value));

aehimself wrote: ↑26.01.2022, 21:25 All is looking fine, except the string field sizes... while TField.Size returned the correct length in characters, I simply cannot get the same result from COLUMN_SIZE, BUFFER_LENGTH and CHAR_OCTET_LENGTH.

We have a varchar field with the maximum length of 6 characters. Oracle reports 24 - 97 - 96, MSSQL (with DBLib) 12 - 12 - 12.

Any hint on this?

aehimself wrote: ↑29.01.2022, 08:59 Now, DBLib reports 24 - 97 - 96 as well on the Varchar(6) field!
I suppose I can use this, only to divide COLUMN_SIZE by 4.
I just don't like magic numbers, that's all

aehimself wrote: ↑29.01.2022, 08:59 Edit: probably connected to the wrong DB. DBLib actually says 6 - 12 - 12, making this an unreliable way to determine the length of a field. Hard-coding magic numbers is bad, hard-coding one per protocol is even worse

Java 11 docs wrote: COLUMN_SIZE int => column size.
CHAR_OCTET_LENGTH int => for char types the maximum number of bytes in the column

aehimself wrote: ↑29.01.2022, 08:59 I'll try to dig into the code to see how Zeos determines field sizes for datasets as it reports everything correctly.

marsupilami wrote: ↑29.01.2022, 13:58So the question would be: What do we want for COLUMN_SIZE to be? And what do oracle ODBC or JDBC drivers report? => Hmm - I might just check the ODBC part...

marsupilami wrote: ↑29.01.2022, 13:58Zeos usually uses the sizes reported by the databases for their result sets and doesn't care about sizes in GetColumns. But this requires you to actually have a result set.

aehimself wrote: ↑29.01.2022, 16:26 To be honest it does not matter. It just has to be consistent imo. Having the maximum character length would be beneficial, as the buffer size (maximum length in bytes) is already reported by the very same metadata in BUFFER_LENGTH. Just reduce by one and it's set.

aehimself wrote: ↑29.01.2022, 16:26 I had a disgusting idea. The metadata actually returns a resultset, so... what if I check the SQLMetaData.FieldByName('COLUMN_NAME').Size (which is always 255 characters) and try to compare that with the size what the resultset metadata returns... SQLMetaData.DbcResultSet.GetMetadata.GetPrecision or .GetScale. Divinding these would give me the driver- and connection specific "magic number".
Unfortunately though, they both return 0 so no luck. I take credit for the idea though, was a nice try