Zeoslib Portal

@EgonHugeist

Michael,
It seems to me that in Zeos7eh1430 the ORACLE BFILE type is not recognized and supported

Michal

@miab3,

Michal did read me a little nit into the Oracle Documentation: http://docs.oracle.com/cd/B28359_01/ser ... #CNCPT1844

BFILE Datatype

The BFILE datatype stores unstructured binary data in operating-system files outside the database. A BFILE column or attribute stores a file locator that points to an external file containing the data. The amount of BFILE data that can be stored is limited by the operating system.

BFILEs are read only; you cannot modify them. They support only random (not sequential) reads, and they do not participate in transactions. The underlying operating system must maintain the file integrity, security, and durability for BFILEs. The database administrator must ensure that the file exists and that Oracle Database processes have operating-system read permissions on the file.

It's a little bit more difficult. Do you have a table definition for this case? As far as i understand Oracle is that type a pointer/FileName? to an external file. For me personally is the description of BFILE less helpfull to know how to support that type. Any Ideas?

Actually i did declare this type as binary-lob because it is a part of the lib descriptions of the oracle documentatian. But how to point now to an external file?

Michael

@EgonHugeist

Here is a simple example of using a BFILE:
http://selvirajan.hubpages.com/hub/BFILE-in-Oracle

Now I get (Zeos7eh1432) error:
... expected BINARY got FILE

ZPlainOracleDriver.pas

{ OCI Data Types }
SQLT_CHR = 1 ;
SQLT_NUM = 2 ;
SQLT_INT = 3 ;
SQLT_FLT = 4 ;
SQLT_STR = 5 ;
SQLT_VNU = 6 ;
SQLT_PDN = 7 ;
SQLT_LNG = 8 ;
SQLT_VCS = 9 ;
SQLT_NON = 10 ;
SQLT_RID = 11 ;
SQLT_DAT = 12 ;
SQLT_VBI = 15 ;
SQLT_BIN = 23 ;
SQLT_LBI = 24 ;
_SQLT_PLI = 29;
SQLT_UIN = 68 ;
SQLT_SLS = 91 ;
SQLT_LVC = 94 ;
SQLT_LVB = 95 ;
SQLT_AFC = 96 ;
SQLT_AVC = 97 ;
SQLT_CUR = 102;
SQLT_RDD = 104;
SQLT_LAB = 105;
SQLT_OSL = 106;
SQLT_NTY = 108;
SQLT_REF = 110;
SQLT_CLOB = 112;
SQLT_BLOB = 113;
SQLT_BFILEE = 114; /// <-----
SQLT_CFILEE = 115; // <-----
SQLT_RSET = 116;
SQLT_NCO = 122;
SQLT_VST = 155;
SQLT_ODT = 156;

Michal

Michal,

forgot to write the Rev... -> 1431. That type is already included now and equal the 'BFILE' for the Meta Informations. but didn't test it yet...

Actually i'm fighting with another issue. I think MySQL is the only PlainDriver which does support all MBCS (Multibyte Charcter Sets). You can see this if you use a standart Grid(without assigned Columuns) and a test-table with string columns. If you open that test-table with MySQL and with another PlainDriver then you'll see the same column displayed in different Length. The Length of MySQL is correct to the Max-Buffer-Size of the String-Field but not to the Char-Count. On the other PlainDrivers this issue is reverted. This is an alltime Zeos Bug.

Example: MySQL: Field1 VARCHAR(30) Utf8_generel_ci means 30x3 Byte. 120 is your visible field-size and DisplayWith now. You can now type in 120 chars. If they are single byte-chars then you'll only get an exception from MySQL that this string is to long. If you use ascendent chars or chinese letters then the string will be cut.
On the other plaindrivers this issue is reverted.

For me personally this is an real bug! The FieldLenght for MySQL i've solved except for a table which is already Meta-cached.
For the other PlainDrivers i've to say there is a lot missing...

Michael

@EgonHugeist

Zeos7eh1433.
Now I get, for example, when opening TZQuery:
List index out of bounds (14)
(Line 1809, "..\..\src\component\ZAbstractRODataset.pas" + 31)


Probably in the case of an error unable to identify the type.

Michal

@EgonHugeist

Michael,
In the case of types that are impossible to identify at the moment could we create a field of a simple fixed type (todo type) and ignore this field of reading and writing data (something like calculated field).

Michal

@miab3,

Michal, i did a roleback of the Component units for this case. I did run my tests and i can't see this exception. But i trust you on that.

In the case of types that are impossible to identify at the moment could we create a field of a simple fixed type (todo type) and ignore this field of reading and writing data (something like calculated field)

Don't know if i understand you right. The CreateFields call does create all fields from the FieldRefs. I was starting from the premise that this is impossible but i fail. Now i'm wondering why this happens.. And much more terrible is that i can't reproduce this issue.

Michal can you explain a little bit more detailed, what you mean?

Rev 1434

Michael

Michal,

After a while.... I do understand you now. Overriding that procedure wasn't a good idea. The db unit calls that pro too. And if there are non data fieds this exceptions is raised. Great mind!

Patch comes this evening.

Again to the memory part. My previous post was a little bit wrong. Zeos allocates the memory for the String fieds in the rowbuffer. One UTF8 char has max Bytes. And Zeos makes this count of bytes x2 for unicode fieds. Actually does it mean a varchar(30) column eats ((30x3)+1[0Byte])x2+2Byte=183Bytes. But we need only 30x2+2=62 Bytes! A Memory wasting! 3times viewer memory! Now imagine exacly that memory is double bufferet for the cached Resultsets....

Michel

@EgonHugeist

Following the 1433 changes that was roleback.

There was then an error which was not previously:

List index out of bounds (8 )

For Oracle table:

CREATE TABLE SYSTEM."ADQA_All_types_DTM"
(
TNVARCHAR2 NVARCHAR2(2000),
TVARCHAR2 VARCHAR2(15),
TNUMBER NUMBER,
TFLOAT FLOAT,
TDATE DATE,
TRAW RAW(18 ),
TROWID ROWID,
TNCHAR NCHAR(1000),
TCHAR CHAR(5)
)

Michal

miab3,

did roleback to 1431 the BFILE patch except some small addidinol thing which do not touch the code yet. The previous two patches had bee the lob subtypes if firebird. But i can not see one line which could result such issues. Didn't test this table now. But i'll do this this evening. Is that exception gone now?

Michael

@EgonHugeist

It seems to me that the error was caused by the procedure CreateFields; override;

Michal

miab3,

Now you make me curious. That procedure and it's override doesn't exists any more since 1433. Which compiler do you use actually?

Michael

@EgonHugeist

Two times I wrote then the error occurred in rev 1433.
Now I'm using rev 1434 and this error does not occur.

Michal

miab3,

oooops, Michal. Yes you wrote it. I'm actually going on playing with the described stuff...

Michael

@EgonHugeist

Michael,
It is hoped to solve the problem of type BFILE in Oracle?

Michal