Re: [Libdbi-drivers-devel] libdbi oracle driver based on ocilib
On 17-Jun-09, at 10:03 AM, Markus Hoenicka wrote: Hi, Quoting Michael Friedrich michael.friedr...@univie.ac.at: I will need to step further into the driver but I wanted to ask * is the driver still in development or left alone? I'd say the driver is pretty much dormant. The latest oracle-specific changes have been committed approx. one year ago. According to what I read on the list, the driver is not in a shape that would allow us to call Oracle fully supported. * possibility of libdbi interface using parameter bindings Is that something like precompiled statements? This would be interesting to have, but I don't see sufficient developer resources to implement this anytime soon. A good bullet point for libdbi-ng though, to join streamed results, and duck-typed column retrieval. (iirc) --Toby regards, Markus -- Markus Hoenicka markus.hoeni...@cats.de (Spam-protected email: replace the quadrupeds with mhoenicka) http://www.mhoenicka.de -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Libdbi-drivers-devel mailing list Libdbi-drivers-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libdbi-drivers-devel -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Libdbi-drivers-devel mailing list Libdbi-drivers-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libdbi-drivers-devel
Re: [Libdbi-drivers-devel] libdbi oracle driver based on ocilib
vincent rogier writes: For example, instead of using cached values (that need extra memory from dbbdi core module while the driver sometimes already hold cached values), the public dbdbi functions like dbi_result_get_int() could use callback to specific drivers functions that delivers the value. This would solve as well the problem of strong typed columns. It would be the driver to return the value as requested, whatever the real type of the column, making its own conversions. That's what OCILIB does. The application requests a column value with a desired type and OCILIB makes conversion if needed and possible. The current cvs revision of libdbi has a lightweight variant of this approach: long long dbi_result_get_as_longlong(); long long dbi_result_get_as_longlong_idx(); char *dbi_result_get_as_string_copy(); char *dbi_result_get_as_string_copy_idx(); These functions return any value as either a long long integer or a string after converting the value returned by the database engine. Client programs can cast the integers to whatever they need. I figured this would cover the most urgent needs. Introducing this possibility through callbacks would not break the actuals drivers. The libdbi core could check if the driver supports this feature and then call its functions. If not, it could work as it does now... This is an interesting idea how to introduce this feature without breaking backwards compatibility. Thanks for sharing this. regards, Markus -- Markus Hoenicka markus.hoeni...@cats.de (Spam-protected email: replace the quadrupeds with mhoenicka) http://www.mhoenicka.de -- Register Now Save for Velocity, the Web Performance Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf ___ Libdbi-drivers-devel mailing list Libdbi-drivers-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libdbi-drivers-devel
Re: [Libdbi-drivers-devel] libdbi oracle driver based on ocilib
On 2-May-09, at 7:15 PM, vincent rogier wrote: No, the sqllite trick cannot be used with Oracle... And even if it was possible, it is not a serious option because it would kill the driver performance People are still coding DB apps in C If it doesn't need to be database independent then there must be many efficient ways to code a C application against Oracle/{your db}. because it's faster... If a C driver has to use exotics and slow behaviors to work, what's the point ? The fact libdbi has to know the number of rows returned by a query, before any fetch, is already a performance bottleneck for some DB, such as Oracle. Agreed. This is a shortcoming of the libdbi API, in my opinion. From Oracle 9i, it's possible to know that, with some big performance loss...(eg. Oracle 8i can't be supported) In the end, the only thing that i need to finish the ocilib based libdbi driver is to solve this problem of integer flags and bits.. Any ideas ? I think the API needs to change to support streamed access to result sets, and loosely typed columns (I suspect we'll see more of this in the future). --Toby (implementor of libdbi Ingres driver) Vincent 2009/5/3 Markus Hoenicka markus.hoeni...@mhoenicka.de vincent rogier writes: So, i'm still suck in the ocilib based libdbo driver to set the integer type bit... For example, a column created as INT (4 bytes integer range) or NUMBER (38 digits for scale and precision that can holds integer, numeric, real, etc..) will be reported by Oracle client library (OCI) as NUMBER... There's no way to make nay difference... So my question : how to deal with that into an libdbi driver ? The sqlite/sqlite3 drivers have to deal with a similar problem. sqlite is essentially typeless, so you can't even distinguish between numbers and text. sqlite3 has something like sticky types but these distinguish only between text and numeric data. The sqlite/sqlite3 drivers have to retrieve the command which was used to create a table (this is fortunately stored in each sqlite database) and figure out which type to use as a return value. This approach has its problems (think functions which mangle values retrieved from several columns) but it mostly works ok. Would that approach be useful for an ocilib based driver? PS : about the actual oracle libdbi driver : the driver can't even compile (syntax problems) and is wrong (LONG types, etc..) and buggy. I'm sure no one has tested it... AFAIK there is no current oracle driver maintainer. Several people have fiddled with the code in the past, but at this time hardly anyone is able to even run the tests in lack of an Oracle installation. It may very well be true that the driver is broken. I can't verify this. regards, Markus -- Markus Hoenicka markus.hoeni...@cats.de (Spam-protected email: replace the quadrupeds with mhoenicka) http://www.mhoenicka.de -- Vincent Rogier -- Register Now Save for Velocity, the Web Performance Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/ velocityconf___ Libdbi-drivers-devel mailing list Libdbi-drivers-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libdbi-drivers-devel -- Register Now Save for Velocity, the Web Performance Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf___ Libdbi-drivers-devel mailing list Libdbi-drivers-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libdbi-drivers-devel
Re: [Libdbi-drivers-devel] libdbi oracle driver based on ocilib
Hi toby, If it doesn't need to be database independent then there must be many efficient ways to code a C application against Oracle/{your db}. True... that's why OCILIB exists :) But implementing an underlying DB layer in a database independent framework can be in tricky (for example : Oracle, actual libdbi driver is broken an incomplete) and reusing existing optimized libraries (like OCILIB) is, i think, a good thing because there is no need to reimplement the layer from scratch. I think, as well, that libdbi should evolve and allow the driver to provide the data when requested by the user. At the moment, libdbi core caches the results when the query is executed and thus has to have a internal strong typed columns model. It would be nice to introduce the possibility for the driver to supply directly the data/informations. For example, instead of using cached values (that need extra memory from dbbdi core module while the driver sometimes already hold cached values), the public dbdbi functions like dbi_result_get_int() could use callback to specific drivers functions that delivers the value. This would solve as well the problem of strong typed columns. It would be the driver to return the value as requested, whatever the real type of the column, making its own conversions. That's what OCILIB does. The application requests a column value with a desired type and OCILIB makes conversion if needed and possible. Introducing this possibility through callbacks would not break the actuals drivers. The libdbi core could check if the driver supports this feature and then call its functions. If not, it could work as it does now... What do you think, Markus ? ps : sorry for my poor English... Vincent. 2009/5/3 Toby Thain t...@telegraphics.com.au On 2-May-09, at 7:15 PM, vincent rogier wrote: No, the sqllite trick cannot be used with Oracle... And even if it was possible, it is not a serious option because it would kill the driver performance People are still coding DB apps in C If it doesn't need to be database independent then there must be many efficient ways to code a C application against Oracle/{your db}. because it's faster... If a C driver has to use exotics and slow behaviors to work, what's the point ? The fact libdbi has to know the number of rows returned by a query, before any fetch, is already a performance bottleneck for some DB, such as Oracle. Agreed. This is a shortcoming of the libdbi API, in my opinion. From Oracle 9i, it's possible to know that, with some big performance loss...(eg. Oracle 8i can't be supported) In the end, the only thing that i need to finish the ocilib based libdbi driver is to solve this problem of integer flags and bits.. Any ideas ? I think the API needs to change to support streamed access to result sets, and loosely typed columns (I suspect we'll see more of this in the future). --Toby (implementor of libdbi Ingres driver) Vincent 2009/5/3 Markus Hoenicka markus.hoeni...@mhoenicka.de vincent rogier writes: So, i'm still suck in the ocilib based libdbo driver to set the integer type bit... For example, a column created as INT (4 bytes integer range) or NUMBER (38 digits for scale and precision that can holds integer, numeric, real, etc..) will be reported by Oracle client library (OCI) as NUMBER... There's no way to make nay difference... So my question : how to deal with that into an libdbi driver ? The sqlite/sqlite3 drivers have to deal with a similar problem. sqlite is essentially typeless, so you can't even distinguish between numbers and text. sqlite3 has something like sticky types but these distinguish only between text and numeric data. The sqlite/sqlite3 drivers have to retrieve the command which was used to create a table (this is fortunately stored in each sqlite database) and figure out which type to use as a return value. This approach has its problems (think functions which mangle values retrieved from several columns) but it mostly works ok. Would that approach be useful for an ocilib based driver? PS : about the actual oracle libdbi driver : the driver can't even compile (syntax problems) and is wrong (LONG types, etc..) and buggy. I'm sure no one has tested it... AFAIK there is no current oracle driver maintainer. Several people have fiddled with the code in the past, but at this time hardly anyone is able to even run the tests in lack of an Oracle installation. It may very well be true that the driver is broken. I can't verify this. regards, Markus -- Markus Hoenicka markus.hoeni...@cats.de (Spam-protected email: replace the quadrupeds with mhoenicka) http://www.mhoenicka.de -- Vincent Rogier -- Register Now Save for Velocity, the Web Performance Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on
Re: [Libdbi-drivers-devel] libdbi oracle driver based on ocilib
Hi Christian, Few hints about the actual Oracle driver : - it cannot compile with a C90 compiler (one line of code to fix to make it compile). - LONG type is handled as an integer instead of a character based type - only few types are handled and all types mapped as strings - numeric types are not handled properly (because of strong libdbi integer typing) - no support for Oracle 8i - output buffers are unnecessary defined at every fetch call The actual driver would need just few fixed and changes to be fully and properly usable. That's an option. I contacted Markus a while ago to propose him to make a oracle driver based of ocilib. Because it was a easy and quick job to implement a driver with OCILIB as it's a full featured and mature library. And using it would allow to have light libdbi glue and let OCILIB work with all Oracle internal details and deal with Oracle versions and new features. By example, new floatting types where addind on 10g and using ocilib, the libdbi glue wouldn't need to be modified. On thing as well, is the runtime Oracle version handling by OCILIB that ajusts its capabilities depending on the Oracle version...etc, ... Anyway, if Markus prefers, i could see and try to fix and update the actual driver. I'm not trying to push ocilib into libdbi, i don't need it.. i just wanted to help :) Vincent. 2009/5/3 Christian Stamgren c...@stamgren.com Hi All, Being the guy who wrote the Oracle driver long time ago (as well as the Firebird and mSQL drivers). Yes, the driver is not completed. There was work left todo when I left the maintainership over to someone else. Unfortunately that someone else didn't finish it either. Most probably he broke more then he fixed as the driver did compile and worked fine in the few projects I used it against (Oracle 9i) when I still took care of it. I think it should be fairly easy to make it work again, although I am not the one that is going to do it. Building a new driver based on a third party library might be a way forward. But that would be a layer on a layer solution. If I where the one coding I would focus on fixing the current Oracle driver that uses OCI directly, not to build a new module from scratch. But as I am not the one coding I would just be happy to get a working driver for Oracle based on anything. So if you are writhing this driver and planning to maintain it, go for it, exchange the oracle driver with your driver. All the best, Christian On May 2, 2009, at 9:45 PM, vincent rogier wrote: Hi markus, I'm coming back about an ocilib based Oracle driver for libdbi. About FreeBSD, There's no official support or package from Oracle Corp. A port has been done and seems to work. The last few weeks, i was in contact with an italian that tried to port OCILIB to FreeBSD. OCILIB compiles well on FreeBDS but there is a problem with the version of the lib C used for the Oracle Client port. I'm still waiting for news... So, the last package i sent you was working well except the numeric types problems... It's not possible to know what size a numeric value really is (1/2/4/8 bytes integers or even numeric...) When you create an INT column or a SHORT column, the storage is the same : oracle NUMBER. Even SQL*PLUS would cannot make the difference. Only the server knows the difference for range checking.. Oracle is different from other database because the client program that tells Oracle how it wants to retreive/insert the value. So, i'm still suck in the ocilib based libdbo driver to set the integer type bit... For example, a column created as INT (4 bytes integer range) or NUMBER (38 digits for scale and precision that can holds integer, numeric, real, etc..) will be reported by Oracle client library (OCI) as NUMBER... There's no way to make nay difference... So my question : how to deal with that into an libdbi driver ? PS : about the actual oracle libdbi driver : the driver can't even compile (syntax problems) and is wrong (LONG types, etc..) and buggy. I'm sure no one has tested it... Regards, Vincent. 2008/11/13 Markus Hoenicka markus.hoeni...@mhoenicka.de vincent rogier writes: I believe it would be more appropriate to call the driver ocilib Sure :). I'll change that Don't rush it. I hoped to get some feedback about the status and the capabilities of the existing oracle driver (which I can't test myself). If the ocilib driver surpasses the oracle driver and is better maintained, then the existing driver is obsolete and should be replaced by the ocilib driver. In that case, oracle wouldn't be a misnomer. However, if for some reason both drivers have to coexist, I'd rather avoid the name clash. Btw, i've got one question about libdbi integer types... Oracle does not make any difference between 1, 2, 4 or 8 bytes integer (from an OCI point of vue). So, as far i've seen about libdbi implementation of datatype (use of unions and
Re: [Libdbi-drivers-devel] libdbi oracle driver based on ocilib
Hi Vincent, You do what is easiest for you, personally iI would like if the current driver using oracle OCI would be fixed but it is not up to me, as I am not going to write it, but it feels kosher for libdbi to use the database own library. There is a list of things I wanted to do in the driver directory written in a file named TODO, those together with your list gives a pretty accurate list of what the driver needs if you choose to fix the current one. But as I said that is up to you. Thanks for your work. Christian On May 3, 2009, at 8:56 PM, vincent rogier wrote: Hi Christian, Few hints about the actual Oracle driver : - it cannot compile with a C90 compiler (one line of code to fix to make it compile). - LONG type is handled as an integer instead of a character based type - only few types are handled and all types mapped as strings - numeric types are not handled properly (because of strong libdbi integer typing) - no support for Oracle 8i - output buffers are unnecessary defined at every fetch call The actual driver would need just few fixed and changes to be fully and properly usable. That's an option. I contacted Markus a while ago to propose him to make a oracle driver based of ocilib. Because it was a easy and quick job to implement a driver with OCILIB as it's a full featured and mature library. And using it would allow to have light libdbi glue and let OCILIB work with all Oracle internal details and deal with Oracle versions and new features. By example, new floatting types where addind on 10g and using ocilib, the libdbi glue wouldn't need to be modified. On thing as well, is the runtime Oracle version handling by OCILIB that ajusts its capabilities depending on the Oracle version...etc, ... Anyway, if Markus prefers, i could see and try to fix and update the actual driver. I'm not trying to push ocilib into libdbi, i don't need it.. i just wanted to help :) Vincent. 2009/5/3 Christian Stamgren c...@stamgren.com Hi All, Being the guy who wrote the Oracle driver long time ago (as well as the Firebird and mSQL drivers). Yes, the driver is not completed. There was work left todo when I left the maintainership over to someone else. Unfortunately that someone else didn't finish it either. Most probably he broke more then he fixed as the driver did compile and worked fine in the few projects I used it against (Oracle 9i) when I still took care of it. I think it should be fairly easy to make it work again, although I am not the one that is going to do it. Building a new driver based on a third party library might be a way forward. But that would be a layer on a layer solution. If I where the one coding I would focus on fixing the current Oracle driver that uses OCI directly, not to build a new module from scratch. But as I am not the one coding I would just be happy to get a working driver for Oracle based on anything. So if you are writhing this driver and planning to maintain it, go for it, exchange the oracle driver with your driver. All the best, Christian On May 2, 2009, at 9:45 PM, vincent rogier wrote: Hi markus, I'm coming back about an ocilib based Oracle driver for libdbi. About FreeBSD, There's no official support or package from Oracle Corp. A port has been done and seems to work. The last few weeks, i was in contact with an italian that tried to port OCILIB to FreeBSD. OCILIB compiles well on FreeBDS but there is a problem with the version of the lib C used for the Oracle Client port. I'm still waiting for news... So, the last package i sent you was working well except the numeric types problems... It's not possible to know what size a numeric value really is (1/2/4/8 bytes integers or even numeric...) When you create an INT column or a SHORT column, the storage is the same : oracle NUMBER. Even SQL*PLUS would cannot make the difference. Only the server knows the difference for range checking.. Oracle is different from other database because the client program that tells Oracle how it wants to retreive/insert the value. So, i'm still suck in the ocilib based libdbo driver to set the integer type bit... For example, a column created as INT (4 bytes integer range) or NUMBER (38 digits for scale and precision that can holds integer, numeric, real, etc..) will be reported by Oracle client library (OCI) as NUMBER... There's no way to make nay difference... So my question : how to deal with that into an libdbi driver ? PS : about the actual oracle libdbi driver : the driver can't even compile (syntax problems) and is wrong (LONG types, etc..) and buggy. I'm sure no one has tested it... Regards, Vincent. 2008/11/13 Markus Hoenicka markus.hoeni...@mhoenicka.de vincent rogier writes: I believe it would be more appropriate to call the driver ocilib Sure :). I'll change that
Re: [Libdbi-drivers-devel] libdbi oracle driver based on ocilib
Hi markus, I'm coming back about an ocilib based Oracle driver for libdbi. About FreeBSD, There's no official support or package from Oracle Corp. A port has been done and seems to work. The last few weeks, i was in contact with an italian that tried to port OCILIB to FreeBSD. OCILIB compiles well on FreeBDS but there is a problem with the version of the lib C used for the Oracle Client port. I'm still waiting for news... So, the last package i sent you was working well except the numeric types problems... It's not possible to know what size a numeric value really is (1/2/4/8 bytes integers or even numeric...) When you create an INT column or a SHORT column, the storage is the same : oracle NUMBER. Even SQL*PLUS would cannot make the difference. Only the server knows the difference for range checking.. Oracle is different from other database because the client program that tells Oracle how it wants to retreive/insert the value. So, i'm still suck in the ocilib based libdbo driver to set the integer type bit... For example, a column created as INT (4 bytes integer range) or NUMBER (38 digits for scale and precision that can holds integer, numeric, real, etc..) will be reported by Oracle client library (OCI) as NUMBER... There's no way to make nay difference... So my question : how to deal with that into an libdbi driver ? PS : about the actual oracle libdbi driver : the driver can't even compile (syntax problems) and is wrong (LONG types, etc..) and buggy. I'm sure no one has tested it... Regards, Vincent. 2008/11/13 Markus Hoenicka markus.hoeni...@mhoenicka.de vincent rogier writes: I believe it would be more appropriate to call the driver ocilib Sure :). I'll change that Don't rush it. I hoped to get some feedback about the status and the capabilities of the existing oracle driver (which I can't test myself). If the ocilib driver surpasses the oracle driver and is better maintained, then the existing driver is obsolete and should be replaced by the ocilib driver. In that case, oracle wouldn't be a misnomer. However, if for some reason both drivers have to coexist, I'd rather avoid the name clash. Btw, i've got one question about libdbi integer types... Oracle does not make any difference between 1, 2, 4 or 8 bytes integer (from an OCI point of vue). So, as far i've seen about libdbi implementation of datatype (use of unions and checks on the integer type flag), there 's no easy and pretty way to deal with it does all other libbdi drivers have no problems like that ? SQlite is essentially typeless. I.e. it won't even distinguish between text and integer. SQLite3 has something called column affinities which helps to distinguish between text and other data types. However, there is no support for different integer types either. The sqlite/sqlite3 drivers use whatever type the column was declared with. Although it doesn't make a difference to SQLite, you *can* declare a column as TINYINT, SMALLINT, INTEGER, or BIGINT, and the drivers rely on you (as a programmer) doing so. OTOH, SQLite wouldn't barf if you store a long long value in a column declared as TINYINT. You wouldn't even lose data if you retrieve the value with sqlite. libdbi would reduce the data to a 1 byte integer upon retrieval though. How does Oracle deal with this? Is there just one integer type? What size is it? Are there any compatibility types to deal with imported data, like MySQL and other engines do? regards, Markus -- Markus Hoenicka markus.hoeni...@cats.de (Spam-protected email: replace the quadrupeds with mhoenicka) http://www.mhoenicka.de -- Vincent Rogier -- Register Now Save for Velocity, the Web Performance Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf___ Libdbi-drivers-devel mailing list Libdbi-drivers-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libdbi-drivers-devel
Re: [Libdbi-drivers-devel] libdbi oracle driver based on ocilib
vincent rogier writes: So, i'm still suck in the ocilib based libdbo driver to set the integer type bit... For example, a column created as INT (4 bytes integer range) or NUMBER (38 digits for scale and precision that can holds integer, numeric, real, etc..) will be reported by Oracle client library (OCI) as NUMBER... There's no way to make nay difference... So my question : how to deal with that into an libdbi driver ? The sqlite/sqlite3 drivers have to deal with a similar problem. sqlite is essentially typeless, so you can't even distinguish between numbers and text. sqlite3 has something like sticky types but these distinguish only between text and numeric data. The sqlite/sqlite3 drivers have to retrieve the command which was used to create a table (this is fortunately stored in each sqlite database) and figure out which type to use as a return value. This approach has its problems (think functions which mangle values retrieved from several columns) but it mostly works ok. Would that approach be useful for an ocilib based driver? PS : about the actual oracle libdbi driver : the driver can't even compile (syntax problems) and is wrong (LONG types, etc..) and buggy. I'm sure no one has tested it... AFAIK there is no current oracle driver maintainer. Several people have fiddled with the code in the past, but at this time hardly anyone is able to even run the tests in lack of an Oracle installation. It may very well be true that the driver is broken. I can't verify this. regards, Markus -- Markus Hoenicka markus.hoeni...@cats.de (Spam-protected email: replace the quadrupeds with mhoenicka) http://www.mhoenicka.de -- Register Now Save for Velocity, the Web Performance Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf ___ Libdbi-drivers-devel mailing list Libdbi-drivers-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libdbi-drivers-devel
Re: [Libdbi-drivers-devel] libdbi oracle driver based on ocilib
No, the sqllite trick cannot be used with Oracle... And even if it was possible, it is not a serious option because it would kill the driver performance People are still coding DB apps in C because it's faster... If a C driver has to use exotics and slow behaviors to work, what's the point ? The fact libdbi has to know the number of rows returned by a query, before any fetch, is already a performance bottleneck for some DB, such as Oracle. From Oracle 9i, it's possible to know that, with some big performance loss...(eg. Oracle 8i can't be supported) In the end, the only thing that i need to finish the ocilib based libdbi driver is to solve this problem of integer flags and bits.. Any ideas ? Vincent 2009/5/3 Markus Hoenicka markus.hoeni...@mhoenicka.de vincent rogier writes: So, i'm still suck in the ocilib based libdbo driver to set the integer type bit... For example, a column created as INT (4 bytes integer range) or NUMBER (38 digits for scale and precision that can holds integer, numeric, real, etc..) will be reported by Oracle client library (OCI) as NUMBER... There's no way to make nay difference... So my question : how to deal with that into an libdbi driver ? The sqlite/sqlite3 drivers have to deal with a similar problem. sqlite is essentially typeless, so you can't even distinguish between numbers and text. sqlite3 has something like sticky types but these distinguish only between text and numeric data. The sqlite/sqlite3 drivers have to retrieve the command which was used to create a table (this is fortunately stored in each sqlite database) and figure out which type to use as a return value. This approach has its problems (think functions which mangle values retrieved from several columns) but it mostly works ok. Would that approach be useful for an ocilib based driver? PS : about the actual oracle libdbi driver : the driver can't even compile (syntax problems) and is wrong (LONG types, etc..) and buggy. I'm sure no one has tested it... AFAIK there is no current oracle driver maintainer. Several people have fiddled with the code in the past, but at this time hardly anyone is able to even run the tests in lack of an Oracle installation. It may very well be true that the driver is broken. I can't verify this. regards, Markus -- Markus Hoenicka markus.hoeni...@cats.de (Spam-protected email: replace the quadrupeds with mhoenicka) http://www.mhoenicka.de -- Vincent Rogier -- Register Now Save for Velocity, the Web Performance Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf___ Libdbi-drivers-devel mailing list Libdbi-drivers-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libdbi-drivers-devel