libopendbx-devel — Help and discussion about OpenDBX

[opendbx] Odbx-sql command tool binary

[Facundo V. <fac...@gm...>]

Hi at all,
I'm trying to compile opendbx-1.4.5 in order to get the binaries of the
utils. I need to use odbx-sql comand line tool to check the whether it's
working fine on my Windows 7 64 bits (WOW64) because It's works properly on
other computer with Windows 7 32 bits.

I did this:

CPPFLAGS="-I/c/Progra~2/GnuWin32/include" \
LDFLAGS="-L/c/Progra~2/GnuWin32/lib" \
./configure --with-backends="pgsql"

and after a lot of succefully checkings I'm getting this:

checking readline/readline.h usability... no
checking readline/readline.h presence... no
checking for readline/readline.h... no
configure: error: libreadline header (readline/readline.h) not found

The GnuWin32 tools are installed on my computer.

Do you know what could be happening?

On the other hand, do anybody have the binary for windows of the utils?

Thanks in advance,
FV

Re: [opendbx] 1.5.0 windows dlls and results

[Mariano M. P. <mar...@gm...>]

Hi Norbert. This is an old thread. In such a mail I have attached all DLLs
for Windows for OpenDBX 1.5. Can we upload such zip to the OpenDBX website?
So far in
http://www.linuxnetworks.de/doc/index.php/OpenDBX/Download#Windows_DLLs
we are linking to 1.4.5:
http://linuxnetworks.de/opendbx/download/opendbx-1.4.5_win32.zip
So it would be nice to link also to the 1.5.

Otherwise, I upload them into our SqueakDBX website. Just let me know.

Best regards and Merry Christmas.

On Sun, Dec 20, 2009 at 12:58 AM, Mariano Martinez Peck <
mar...@gm...> wrote:

>
>
> On Thu, Dec 17, 2009 at 9:41 PM, Norbert Sendetzky <
> no...@li...> wrote:
>
>> Hi Mariano
>>
>> > Hi Norbert. I just wanted to let you know that I compile all backends in
>> > Linux and Windows and all my tests are green. Even ODBC in windows is
>> > working :)   I have a little problem, but I will ask then.
>> >
>> > I also generated dlls for windows. I attach a zip with them.
>>
>> If you manage it to also create the backends for firebird and sybase so we
>> have a full package, I will upload your Windows DLLs :-)
>>
>>
> you make me work ;)
>
> Ok...I installed both for my first time in my life :)
> For sybase, there is another thread. Would be excellent if you can test
> that dll regardless my problem. At least to see if the dlls i generate work
> ok.
>
> I could successfully compile and install Firebird...even more, of my 95
> squeakdbx unit tests, I have only 10 failing but I think it is nothing
> important and it is fixable :)   So, good nows!!!     This was only tested
> in Windows. I will test it in Linux when I have more time.
>
> I attach here all windows dlls.
>
> cheers,
>
> Mariano
>
>
>>
>> Norbert
>> --
>> OpenPGP public key
>> http://www.linuxnetworks.de/norbert.pubkey.asc
>>
>>
>>
>> ------------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Verizon Developer Community
>> Take advantage of Verizon's best-in-class app development support
>> A streamlined, 14 day to market process makes app distribution fast and
>> easy
>> Join now and get one step closer to millions of Verizon customers
>> http://p.sf.net/sfu/verizon-dev2dev
>> _______________________________________________
>> libopendbx-devel mailing list
>> lib...@li...
>> https://lists.sourceforge.net/lists/listinfo/libopendbx-devel
>> http://www.linuxnetworks.de/doc/index.php/OpenDBX
>>
>>
>


-- 
Mariano
http://marianopeck.wordpress.com

Re: [opendbx] Several problems with OpenDBX

[Norbert S. <no...@li...>]

On 10/25/2011 10:06 PM, Alex Ott wrote:
>> Yes, the sqlite3 backend doesn't care about slashes/backslashes at the
>> end of the path, so it don't have to care about Unix/Windows differences
>> (also noted here:
>> http://linuxnetworks.de/doc/index.php/OpenDBX/Configuration#sqlite3_backend)
>
> This could be noted, but simple patch can fix this, making better experience

Your patch is not enough as it misses the handling for the differences 
between Unix/Windows. If I would add your patch as is, the code for the 
sqlite3 backend would stop working on Windows systems.

>> If you don't let the destructor do the work, you have to care about the
>> correct sequence yourself (new Conn(), bind(), ..., unbind(), finish()).
>> It's the same as in the procedural interface. Maybe we can improve the
>> situation if we call Conn.unbind() in Conn.finish() if it's not done before.
>
> I allow destructor to care, but it should depend on which functions
> was called already&  which not...

Done in rev. 354

> P.S. I already switched from OpenDBX, as using it I got mysterious
> crashes due memory corruption...

Sorry to hear that.


Norbert

Re: [opendbx] Several problems with OpenDBX

[Alex O. <al...@gm...>]

Re

On Tue, Oct 25, 2011 at 10:01 PM, Norbert Sendetzky
<no...@li...> wrote:
> Hi Alex
>
>> I'm evaluating OpenDBX for use in one of my projects, and found several errors:
>>   - sqlite3 backend doesn't check that host parameter ends with /, and
>> simply appends database name to path, creating incorrect file name. I
>> attached simple patch to fix this - it checks, that path ends with /,
>> and if not, then adds it. The only improvement that should be made
>> there - add preprocessor condition to select / or \ depending on
>> platform used (unix or windows)
>
> Yes, the sqlite3 backend doesn't care about slashes/backslashes at the
> end of the path, so it don't have to care about Unix/Windows differences
> (also noted here:
> http://linuxnetworks.de/doc/index.php/OpenDBX/Configuration#sqlite3_backend)

This could be noted, but simple patch can fix this, making better experience

>>   - second problem is more serious - it crash, when following
>> combination of commands was used:
>> 1. create connection
>> 2. bind
>> 3. do select
>> 4. retrieve results
>> 5. call result.finish();
>> 6. call connection.finish();
>>
>> the problem is that if I call finish(), then unbind isn't called,
>> while finish will free database handle, that will be used in Conn
>> destructor, to perform unbind. I'm not sure how it's better to fix
>> this - one potential solution, is to use odbx_t** as parameter to
>> odbx_finish, so it will set handle to NULL, after it will freed.
>
> If you don't let the destructor do the work, you have to care about the
> correct sequence yourself (new Conn(), bind(), ..., unbind(), finish()).
> It's the same as in the procedural interface. Maybe we can improve the
> situation if we call Conn.unbind() in Conn.finish() if it's not done before.

I allow destructor to care, but it should depend on which functions
was called already & which not...

P.S. I already switched from OpenDBX, as using it I got mysterious
crashes due memory corruption...

-- 
With best wishes,                    Alex Ott
http://alexott.net/
Tiwtter: alexott_en (English), alexott (Russian)
Skype: alex.ott

Re: [opendbx] Several problems with OpenDBX

[Norbert S. <no...@li...>]

Hi Alex

> I'm evaluating OpenDBX for use in one of my projects, and found several errors:
>   - sqlite3 backend doesn't check that host parameter ends with /, and
> simply appends database name to path, creating incorrect file name. I
> attached simple patch to fix this - it checks, that path ends with /,
> and if not, then adds it. The only improvement that should be made
> there - add preprocessor condition to select / or \ depending on
> platform used (unix or windows)

Yes, the sqlite3 backend doesn't care about slashes/backslashes at the 
end of the path, so it don't have to care about Unix/Windows differences 
(also noted here: 
http://linuxnetworks.de/doc/index.php/OpenDBX/Configuration#sqlite3_backend)

>   - second problem is more serious - it crash, when following
> combination of commands was used:
> 1. create connection
> 2. bind
> 3. do select
> 4. retrieve results
> 5. call result.finish();
> 6. call connection.finish();
>
> the problem is that if I call finish(), then unbind isn't called,
> while finish will free database handle, that will be used in Conn
> destructor, to perform unbind. I'm not sure how it's better to fix
> this - one potential solution, is to use odbx_t** as parameter to
> odbx_finish, so it will set handle to NULL, after it will freed.

If you don't let the destructor do the work, you have to care about the 
correct sequence yourself (new Conn(), bind(), ..., unbind(), finish()). 
It's the same as in the procedural interface. Maybe we can improve the 
situation if we call Conn.unbind() in Conn.finish() if it's not done before.


Norbert

[opendbx] Several problems with OpenDBX

[Alex O. <al...@gm...>]

Hello all

I'm evaluating OpenDBX for use in one of my projects, and found several errors:
 - sqlite3 backend doesn't check that host parameter ends with /, and
simply appends database name to path, creating incorrect file name. I
attached simple patch to fix this - it checks, that path ends with /,
and if not, then adds it. The only improvement that should be made
there - add preprocessor condition to select / or \ depending on
platform used (unix or windows)

 - second problem is more serious - it crash, when following
combination of commands was used:
1. create connection
2. bind
3. do select
4. retrieve results
5. call result.finish();
6. call connection.finish();

the problem is that if I call finish(), then unbind isn't called,
while finish will free database handle, that will be used in Conn
destructor, to perform unbind. I'm not sure how it's better to fix
this - one potential solution, is to use odbx_t** as parameter to
odbx_finish, so it will set handle to NULL, after it will freed.

Should I create bug for this issues?

-- 
With best wishes,                    Alex Ott
http://alexott.net/
Tiwtter: alexott_en (English), alexott (Russian)
Skype: alex.ott

Re: [opendbx] Fedora packaging efforts

[Norbert S. <no...@li...>]

Hi Martin

> I am trying to get opendbx into Fedora. I have run into several
> smaller problems that you might be interested in fixing:

Fixed in stable 1.4 branch. Are there any other problem that I can fix?

> Even though the library is licensed under LGPLv2+, files
> util/argmap.{cpp,hpp} have GPLv2+ header in them. Is this just an
> oversight or are they really meant to be licensed under GPL? In the
> meantime I will use GPLv2+ in the spec file to be on the safe side.

I've changed the license to LGPL2+ in the header of the two files. This 
should be no problem as the code is completely written by myself even if 
it's heavily inspired by the PowerDNS ArgMap code.


Norbert

[opendbx] Fedora packaging efforts

[Martin P. <mpr...@re...>]

Hi,
I am trying to get opendbx into Fedora. I have run into several smaller problems that you might be interested in fixing:

Incorrect FSF addresses:
opendbx-debuginfo.x86_64: E: incorrect-fsf-address
/usr/src/debug/opendbx-1.4.5/utils/argmap.hpp
opendbx-debuginfo.x86_64: E: incorrect-fsf-address
/usr/src/debug/opendbx-1.4.5/utils/argmap.cpp

Even though the library is licensed under LGPLv2+, files util/argmap.{cpp,hpp} have GPLv2+ header in them. Is this just an oversight or are they really meant to be licensed under GPL? In the meantime I will use GPLv2+ in the spec file to be on the safe side.

Bugzilla link: https://bugzilla.redhat.com/show_bug.cgi?id=739856

Kind regards,
Martin Preisler

Re: [opendbx] Lookup of backend libraries fails - why?

[Norbert S. <no...@li...>]

Hi Mariano

> CFLAGS="-m32" \
> CXXFLAGS="-m32" \
> CPPFLAGS="-m32 -I/opendbx/PostgreSQL/9.0/include -I/opendbx/mysql/5.0/include" \
> LDFLAGS="-m32 -L/opendbx/PostgreSQL/9.0/lib -L/opendbx/mysql/5.0/lib" \
> ./configure --disable-utils --with-backends="mysql pgsql"
>
> Now...let's say I have renamed /opendbx to /dbx
> what should happen?  should openDBX file while trying to get the library?
> is it linked statically or it can be searched dinamically?
> Why we ask this?  because we want to distribute an Smalltalk app for new
> comers/newbiews where we include the binary of OpenDBX. But if this is
> statically linked to the database client library then we cannot do it.

If you move the database drivers (located in /opendbx during compile 
time) to another directory (like /dbx), the drivers are not found any 
more if you don't help the libopendbx.so library to find them. The 
reason for this is, that most OS don't support searching for libraries 
relative to the configured paths, e.g. if /usr/lib is the standard path, 
then /usr/lib/opendbx/libmysqlbackend.so is not found if you tell the 
library to look for opendbx/libmysqlbackend.so. There are currently two 
ways to get around this:

1.) During compile time, the absolute path where the backends can be 
found is included into libopendbx.so. Thus, if you move them to another 
directory, lookup fails without further hints
2.) You can use an absolute or relative path to the backend for the 
"backend" parameter, e.g. instead of "mysql" use 
"../../backends/libmysqlbackend.so"

> The second question was to know if this depends on the OS and if true if you
> know which is the case in linux/mac/windows. I don't know why, but if I
> remember correctly, in Windows I was able to do this. I mean, the dll of the
> database client library was search dinamically in those places where Windows
> searchs...

Windows is an exception in this case because it allows relative paths 
for searching backends. It's the first case where I'm thinking that 
Windows is doing better than Unix in this area :-)


Norbert

[opendbx] Basic questions I still don't understand ;)

[Mariano M. P. <mar...@gm...>]

Hi Norbert. I have 2 very basic questions ;)

Several months ago I compiled OpenDBX for first time in MacOS. Now I try to
use it again, and I have an error that the mysql library was not found. The
thing is that when I compiled OpenDBX I did something like:

CFLAGS="-m32" \
CXXFLAGS="-m32" \
CPPFLAGS="-m32 -I/opendbx/PostgreSQL/9.0/include -I/opendbx/mysql/5.0/include" \
LDFLAGS="-m32 -L/opendbx/PostgreSQL/9.0/lib -L/opendbx/mysql/5.0/lib" \
./configure --disable-utils --with-backends="mysql pgsql"


Now...let's say I have renamed /opendbx to /dbx
what should happen?  should openDBX file while trying to get the library?
is it linked statically or it can be searched dinamically?
Why we ask this?  because we want to distribute an Smalltalk app for new
comers/newbiews where we include the binary of OpenDBX. But if this is
statically linked to the database client library then we cannot do it.

The second question was to know if this depends on the OS and if true if you
know which is the case in linux/mac/windows. I don't know why, but if I
remember correctly, in Windows I was able to do this. I mean, the dll of the
database client library was search dinamically in those places where Windows
searchs...


Thanks!

-- 
Mariano
http://marianopeck.wordpress.com

Re: [opendbx] Postgresql + bytea data type

[Guillermo P. <gui...@gm...>]

Hmm, I supposed that! :P

As soon as we are done with the mayor taks of DBXTalk, we will give you a
hand in opendbx ;).

Thanks!!
Guille

On Thu, Sep 22, 2011 at 3:10 AM, Norbert Sendetzky <no...@li...
> wrote:

> Hi Guille
>
> > I was trying to query a *bytea* from a postgresql database with opendbx
> and
> > I'm getting a UNKNOWN type from it :(.  However, the value retrieved
> looks
> > ok.
> >
> > I was looking at
> > http://www.linuxnetworks.de/doc/index.php/OpenDBX/DBMS_Datatypes but
> there
> > is no mention of the *bytea*.
> >
> > Are you planning to support bytea?
>
> Bytea data is something PostgreSQL specific and it can't be mapped to
> any standard ANSI SQL data type so no, this doesn't seem to be possible.
> There's a patch from Zhao Tongyi (from 2011-07-11) to add support for
> encoding/decoding but the pgsql backend but the approach is not optimal.
> It would be better to add another interface to the library that returns
> the bare connection handle so specific things only available for the
> specific backend would be possible to do. If someone would be able to
> provide a patch for this against 1.5.x, I would be happy to integrate it
> into SVN.
>
>
> Norbert
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1
> _______________________________________________
> libopendbx-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libopendbx-devel
> http://www.linuxnetworks.de/doc/index.php/OpenDBX
>

Re: [opendbx] Postgresql + bytea data type

[Norbert S. <no...@li...>]

Hi Guille

> I was trying to query a *bytea* from a postgresql database with opendbx and
> I'm getting a UNKNOWN type from it :(.  However, the value retrieved looks
> ok.
>
> I was looking at
> http://www.linuxnetworks.de/doc/index.php/OpenDBX/DBMS_Datatypes but there
> is no mention of the *bytea*.
>
> Are you planning to support bytea?

Bytea data is something PostgreSQL specific and it can't be mapped to 
any standard ANSI SQL data type so no, this doesn't seem to be possible. 
There's a patch from Zhao Tongyi (from 2011-07-11) to add support for 
encoding/decoding but the pgsql backend but the approach is not optimal. 
It would be better to add another interface to the library that returns 
the bare connection handle so specific things only available for the 
specific backend would be possible to do. If someone would be able to 
provide a patch for this against 1.5.x, I would be happy to integrate it 
into SVN.


Norbert

Re: [opendbx] Sqlite answering rows all the time?

[Norbert S. <no...@li...>]

Hi Guillermo

> could you see this?

Yes, I saw it and your solution but I'm currently extremely busy in my 
job, so I haven't got a chance to look deeper in this topic.

I don't know yet if your patch has some side effects. The correct 
behavior would be if sqlite3_odbx_row_fetch() always return 
ODBX_ROW_DONE when no more rows are available. That doesn't seem to be 
the case with your patch. If you find a way to achieve this, I would be 
happy to add your patch to the SVN repository.


Norbert

[opendbx] Postgresql + bytea data type

[Guillermo P. <gui...@gm...>]

Hi Norbert!

I was trying to query a *bytea* from a postgresql database with opendbx and
I'm getting a UNKNOWN type from it :(.  However, the value retrieved looks
ok.

I was looking at
http://www.linuxnetworks.de/doc/index.php/OpenDBX/DBMS_Datatypes but there
is no mention of the *bytea*.

Are you planning to support bytea?

Thanks!
Guille

Re: [opendbx] Sqlite answering rows all the time?

[Guillermo P. <gui...@gm...>]

Hi Norbert,

could you see this?

Thanks!

On Tue, Aug 23, 2011 at 12:20 PM, Guillermo Polito <
gui...@gm...> wrote:

> BTW, I've ran the bunch of tests we have for SQLite (about 110) and they
> are still working :).  So I hope this change does not introduce any strange
> behavior.
>
>
> On Tue, Aug 23, 2011 at 12:07 PM, Guillermo Polito <
> gui...@gm...> wrote:
>
>> I've managed to fix this adding these two lines :)
>>
>> static int sqlite3_odbx_row_fetch( odbx_result_t* result )
>> {
>>     DEBUGLOG( result->handle->log.write( &(result->handle->log), 1,
>> "sqlite3_odbx_row_fetch() called" ); )
>>
>>     struct sconn* aux = (struct sconn*) result->handle->aux;
>>
>>     if( aux == NULL ) { return -ODBX_ERR_PARAM; }
>>
>>     int err = aux->err;
>>
>>     if( err != -1 ) { aux->err = -1; }   // use original error code the
>> first time
>>     else { err = sqlite3_step( (sqlite3_stmt*) result->generic ); }
>>
>>     switch( err )
>>     {
>>         case SQLITE_ROW:
>>             return ODBX_ROW_NEXT;
>>         case SQLITE_DONE:
>>         case SQLITE_OK:
>>         case SQLITE_MISUSE:   // Return DONE if function called more often
>> afterwards
>>  >>           sqlite3_finalize( (sqlite3_stmt*) result->generic );
>>  >>           result->generic = NULL;
>>             return ODBX_ROW_DONE;
>>     }
>>
>>     return -ODBX_ERR_BACKEND;
>> }
>>
>> But I don't know if they are correct.  Maybe they are bit meant to be
>> there and we should manage it on our side, hehe.
>>
>> Guille
>>
>>
>> On Tue, Aug 23, 2011 at 7:37 AM, Guillermo Polito <
>> gui...@gm...> wrote:
>>
>>> Actually, It answers the ODBX_ROW_DONE, but afterwards, if we continue
>>> asking for more rows, we get ODBX_ROW_NEXT again.
>>>
>>> Thanks!
>>>
>>>
>>> On Tue, Aug 23, 2011 at 7:25 AM, Mariano Martinez Peck <
>>> mar...@gm...> wrote:
>>>
>>>> Hi Norbert. We found a problem with Sqlie and I wonder if it is our
>>>> fault or not.
>>>> Imagine we send a query and we iterate the resultset with odbx_row_fetch
>>>>
>>>> Now...imagine the query answered 3 rows. We invoke odbx_row_fetch times
>>>> and we correctly get the rows. Now...the problem is that it does NOT answers
>>>> ODBX_ROW_DONE ("0") but instead  ODBX_ROW_NEXT ("1") . Hence, we assume we
>>>> can continue asking rows. And in fact, if we continue invoking that function
>>>> 3 more times, we get AGAIN those 3 rows...
>>>>
>>>> So...shouldn't this answer ODBX_ROW_DONE after the 3 times I invoked
>>>> odbx_row_fetch ?
>>>>
>>>> Thanks a lot in advance
>>>>
>>>> --
>>>> Mariano
>>>> http://marianopeck.wordpress.com
>>>>
>>>>
>>>
>>
>

Re: [opendbx] Sqlite answering rows all the time?

[Guillermo P. <gui...@gm...>]

BTW, I've ran the bunch of tests we have for SQLite (about 110) and they are
still working :).  So I hope this change does not introduce any strange
behavior.

On Tue, Aug 23, 2011 at 12:07 PM, Guillermo Polito <
gui...@gm...> wrote:

> I've managed to fix this adding these two lines :)
>
> static int sqlite3_odbx_row_fetch( odbx_result_t* result )
> {
>     DEBUGLOG( result->handle->log.write( &(result->handle->log), 1,
> "sqlite3_odbx_row_fetch() called" ); )
>
>     struct sconn* aux = (struct sconn*) result->handle->aux;
>
>     if( aux == NULL ) { return -ODBX_ERR_PARAM; }
>
>     int err = aux->err;
>
>     if( err != -1 ) { aux->err = -1; }   // use original error code the
> first time
>     else { err = sqlite3_step( (sqlite3_stmt*) result->generic ); }
>
>     switch( err )
>     {
>         case SQLITE_ROW:
>             return ODBX_ROW_NEXT;
>         case SQLITE_DONE:
>         case SQLITE_OK:
>         case SQLITE_MISUSE:   // Return DONE if function called more often
> afterwards
>  >>           sqlite3_finalize( (sqlite3_stmt*) result->generic );
>  >>           result->generic = NULL;
>             return ODBX_ROW_DONE;
>     }
>
>     return -ODBX_ERR_BACKEND;
> }
>
> But I don't know if they are correct.  Maybe they are bit meant to be there
> and we should manage it on our side, hehe.
>
> Guille
>
>
> On Tue, Aug 23, 2011 at 7:37 AM, Guillermo Polito <
> gui...@gm...> wrote:
>
>> Actually, It answers the ODBX_ROW_DONE, but afterwards, if we continue
>> asking for more rows, we get ODBX_ROW_NEXT again.
>>
>> Thanks!
>>
>>
>> On Tue, Aug 23, 2011 at 7:25 AM, Mariano Martinez Peck <
>> mar...@gm...> wrote:
>>
>>> Hi Norbert. We found a problem with Sqlie and I wonder if it is our fault
>>> or not.
>>> Imagine we send a query and we iterate the resultset with odbx_row_fetch
>>>
>>> Now...imagine the query answered 3 rows. We invoke odbx_row_fetch times
>>> and we correctly get the rows. Now...the problem is that it does NOT answers
>>> ODBX_ROW_DONE ("0") but instead  ODBX_ROW_NEXT ("1") . Hence, we assume we
>>> can continue asking rows. And in fact, if we continue invoking that function
>>> 3 more times, we get AGAIN those 3 rows...
>>>
>>> So...shouldn't this answer ODBX_ROW_DONE after the 3 times I invoked
>>> odbx_row_fetch ?
>>>
>>> Thanks a lot in advance
>>>
>>> --
>>> Mariano
>>> http://marianopeck.wordpress.com
>>>
>>>
>>
>

Re: [opendbx] Sqlite answering rows all the time?

[Guillermo P. <gui...@gm...>]

I've managed to fix this adding these two lines :)

static int sqlite3_odbx_row_fetch( odbx_result_t* result )
{
    DEBUGLOG( result->handle->log.write( &(result->handle->log), 1,
"sqlite3_odbx_row_fetch() called" ); )

    struct sconn* aux = (struct sconn*) result->handle->aux;

    if( aux == NULL ) { return -ODBX_ERR_PARAM; }

    int err = aux->err;

    if( err != -1 ) { aux->err = -1; }   // use original error code the
first time
    else { err = sqlite3_step( (sqlite3_stmt*) result->generic ); }

    switch( err )
    {
        case SQLITE_ROW:
            return ODBX_ROW_NEXT;
        case SQLITE_DONE:
        case SQLITE_OK:
        case SQLITE_MISUSE:   // Return DONE if function called more often
afterwards
 >>           sqlite3_finalize( (sqlite3_stmt*) result->generic );
 >>           result->generic = NULL;
            return ODBX_ROW_DONE;
    }

    return -ODBX_ERR_BACKEND;
}

But I don't know if they are correct.  Maybe they are bit meant to be there
and we should manage it on our side, hehe.

Guille

On Tue, Aug 23, 2011 at 7:37 AM, Guillermo Polito <gui...@gm...
> wrote:

> Actually, It answers the ODBX_ROW_DONE, but afterwards, if we continue
> asking for more rows, we get ODBX_ROW_NEXT again.
>
> Thanks!
>
>
> On Tue, Aug 23, 2011 at 7:25 AM, Mariano Martinez Peck <
> mar...@gm...> wrote:
>
>> Hi Norbert. We found a problem with Sqlie and I wonder if it is our fault
>> or not.
>> Imagine we send a query and we iterate the resultset with odbx_row_fetch
>>
>> Now...imagine the query answered 3 rows. We invoke odbx_row_fetch times
>> and we correctly get the rows. Now...the problem is that it does NOT answers
>> ODBX_ROW_DONE ("0") but instead  ODBX_ROW_NEXT ("1") . Hence, we assume we
>> can continue asking rows. And in fact, if we continue invoking that function
>> 3 more times, we get AGAIN those 3 rows...
>>
>> So...shouldn't this answer ODBX_ROW_DONE after the 3 times I invoked
>> odbx_row_fetch ?
>>
>> Thanks a lot in advance
>>
>> --
>> Mariano
>> http://marianopeck.wordpress.com
>>
>>
>

Re: [opendbx] Sqlite answering rows all the time?

[Guillermo P. <gui...@gm...>]

Actually, It answers the ODBX_ROW_DONE, but afterwards, if we continue
asking for more rows, we get ODBX_ROW_NEXT again.

Thanks!

On Tue, Aug 23, 2011 at 7:25 AM, Mariano Martinez Peck <
mar...@gm...> wrote:

> Hi Norbert. We found a problem with Sqlie and I wonder if it is our fault
> or not.
> Imagine we send a query and we iterate the resultset with odbx_row_fetch
>
> Now...imagine the query answered 3 rows. We invoke odbx_row_fetch times and
> we correctly get the rows. Now...the problem is that it does NOT answers
> ODBX_ROW_DONE ("0") but instead  ODBX_ROW_NEXT ("1") . Hence, we assume we
> can continue asking rows. And in fact, if we continue invoking that function
> 3 more times, we get AGAIN those 3 rows...
>
> So...shouldn't this answer ODBX_ROW_DONE after the 3 times I invoked
> odbx_row_fetch ?
>
> Thanks a lot in advance
>
> --
> Mariano
> http://marianopeck.wordpress.com
>
>

[opendbx] Sqlite answering rows all the time?

[Mariano M. P. <mar...@gm...>]

Hi Norbert. We found a problem with Sqlie and I wonder if it is our fault or
not.
Imagine we send a query and we iterate the resultset with odbx_row_fetch

Now...imagine the query answered 3 rows. We invoke odbx_row_fetch times and
we correctly get the rows. Now...the problem is that it does NOT answers
ODBX_ROW_DONE ("0") but instead  ODBX_ROW_NEXT ("1") . Hence, we assume we
can continue asking rows. And in fact, if we continue invoking that function
3 more times, we get AGAIN those 3 rows...

So...shouldn't this answer ODBX_ROW_DONE after the 3 times I invoked
odbx_row_fetch ?

Thanks a lot in advance

-- 
Mariano
http://marianopeck.wordpress.com

Re: [opendbx] Problems compiling opendbx on windows with latestMinGW and msys

[Mariano M. P. <mar...@gm...>]

On Mon, Aug 15, 2011 at 12:18 PM, Alain Rastoul <al...@fr...> wrote:

> **
> Hi,
>
> Just to let you know that I finally solved this problem adding
> LDFLAGS = -lintl
> to the sqlite3 backend makefile of opendbx
> I think a better way to do this would be to add it  somwhere in the
> configure script.
>
>

Norbert, do you think this should be added to OpenDBX makefiles?

Thanks



> Cheers
> Alain
>
>
> "Alain Rastoul" <alr...@pu... <al...@fr...>> a
> écrit dans le message de news: j285sb$mf0$1...@do......
> Hi Guillermo
>
> Did you solve your compiling problem undefined reference to
> libintl_dgettext ?
> I have the same problem trying to build the sqlite3 backend.
> TIA
> Alain
>
> "Guillermo Polito" <gui...@gm...> a écrit dans le message de
> news:
> CAOBmb50Te7k=Xan...@pu...<CAOBmb50Te7k=Xan...@ma...>
> ...
> Ok, I tried all that without success :S.
>
> But, I tried for the second time to use the compiled dlls from the site-I
> dunno why the first time did not work-, pasting them into Windows\system32,
> and it worked, so I'm freezing the open dbx building for now.
>
> Thanks for all your help, and sorry for the spam :).
>
> Guille
>
> On Mon, Jul 11, 2011 at 7:42 AM, Mariano Martinez Peck <
> mar...@gm...> wrote:
>
>> Guille I think that a possible solution can be to create the variable
>> $PATH and add it to  C:\MinGW\lib\
>> or to whereever you have the lib folder of mingw.
>>
>> In your $PATH I can see you don't put :/mingw/lib
>>
>> Guille $PATH
>>
>>
>> .:/usr/local/bin:/mingw/bin:/bin:/usr/local/bin:/usr/bin:/c/WINDOWS/system32:/c/WINDOWS:/c/WINDOWS/System32/Wbem:/c/Archivos
>> de
>> programa/QuickTime/QTSystem/:/c/WINDOWS/system32/WindowsPowerShell/v1.0:/c/Archivos
>> de programa/Microsoft SQL Server/90/Tools/binn/:/mingw/bin/
>>
>> But I do:
>>
>> $ echo $PATH
>>
>> .:/usr/local/bin:/mingw/bin:/bin:/c/oraclexe/app/oracle/product/10.2.0/server/bin:/c/Sybase/OCS-15_0/dll:/c/Sybase/ASE-15_0/jobscheduler/bin:/c/Sybase/ASE-15_0/dll:/c/Sybase/ASE-15_0/bin:/c/Sybase/DBISQL/bin:/c/Sybase/DataAccess/ADONET/dll:/c/Sybase/DataAccess/ODBC/dll:/c/Sybase/DataAccess/OLEDB/dll:/c/Sybase/UAF-2_5/bin:/c/Sybase/OCS-15_0/lib3p:/c/Sybase/OCS-15_0/dll:/c/Sybase/OCS-15_0/bin:/c/SQLServer:/c/mariano/oracle/instantclient_11_1/:/mingw/bin:
>> /mingw/lib:/lib/:/usr/bin:/c/WINDOWS/system32:/c/WINDOWS:/c/WINDOWS/System32/Wbem:/c/Archivos
>> de programa/TortoiseSVN/bin:/c/PostgreSQL/8.3/bin/:/c/Archivos de
>> programa/Microsoft SQL
>> Server/90/Tools/binn/:/c/XEClient/bin:/c/MySQL/bin:/c/Archivos de
>> programa/CMake 2.8/bin:/c/Archivos de programa/Git/cmd:/c/Archivos de
>> programa/Git/bin:/c/Archivos de programa/Cincom/ObjectStudio/dllw32:./dllw32
>>
>>
>> In addition, maybe we can do something like
>>
>> --disable-nls
>>
>> during ./configure   ?
>>
>> tell me if  helped
>>
>> On Sat, Jul 9, 2011 at 10:41 PM, Guillermo Polito <
>> gui...@gm...> wrote:
>>
>>> Yeap.  I'm now trying to use Cygwin instead.  I'll tell you if I can
>>> succeed :).
>>>
>>> Thanks!
>>>
>>>
>>> On Sat, Jul 9, 2011 at 5:39 PM, Norbert Sendetzky <
>>> no...@li...> wrote:
>>>
>>>> Hi Guille
>>>>
>>>> > Do you think it's a problem with my minGW instalation?  I've also
>>>> installed
>>>> > the package in http://gnuwin32.sourceforge.net/packages/gettext.htmto see
>>>> > if it makes some difference.
>>>>
>>>> Yes, I think so. Did you used the documentation as reference?
>>>>
>>>>
>>>> http://linuxnetworks.de/doc/index.php/OpenDBX/Setup/Windows/Building_with_MinGW
>>>>
>>>>
>>>> Norbert
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> All of the data generated in your IT infrastructure is seriously
>>>> valuable.
>>>> Why? It contains a definitive record of application performance,
>>>> security
>>>> threats, fraudulent activity, and more. Splunk takes this data and makes
>>>> sense of it. IT sense. And common sense.
>>>> http://p.sf.net/sfu/splunk-d2d-c2
>>>> _______________________________________________
>>>> libopendbx-devel mailing list
>>>> lib...@pu...
>>>> https://lists.sourceforge.net/lists/listinfo/libopendbx-devel
>>>> http://www.linuxnetworks.de/doc/index.php/OpenDBX
>>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> All of the data generated in your IT infrastructure is seriously
>>> valuable.
>>> Why? It contains a definitive record of application performance, security
>>> threats, fraudulent activity, and more. Splunk takes this data and makes
>>> sense of it. IT sense. And common sense.
>>> http://p.sf.net/sfu/splunk-d2d-c2
>>> _______________________________________________
>>> libopendbx-devel mailing list
>>> lib...@pu...
>>> https://lists.sourceforge.net/lists/listinfo/libopendbx-devel
>>> http://www.linuxnetworks.de/doc/index.php/OpenDBX
>>>
>>>
>>
>>
>> --
>> Mariano
>> http://marianopeck.wordpress.com
>>
>>
>>
>> ------------------------------------------------------------------------------
>> All of the data generated in your IT infrastructure is seriously valuable.
>> Why? It contains a definitive record of application performance, security
>> threats, fraudulent activity, and more. Splunk takes this data and makes
>> sense of it. IT sense. And common sense.
>> http://p.sf.net/sfu/splunk-d2d-c2
>> _______________________________________________
>> libopendbx-devel mailing list
>> lib...@pu...
>> https://lists.sourceforge.net/lists/listinfo/libopendbx-devel
>> http://www.linuxnetworks.de/doc/index.php/OpenDBX
>>
>>
>  ------------------------------
>
>
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
>
> ------------------------------
>
>  ------------------------------
>
>
> ------------------------------------------------------------------------------
> FREE DOWNLOAD - uberSVN with Social Coding for Subversion.
> Subversion made easy with a complete admin console. Easy
> to use, easy to manage, easy to install, easy to extend.
> Get a Free download of the new open ALM Subversion platform now.
> http://p.sf.net/sfu/wandisco-dev2dev
>
> ------------------------------
>
>
>
> ------------------------------------------------------------------------------
> uberSVN's rich system and user administration capabilities and model
> configuration take the hassle out of deploying and managing Subversion and
> the tools developers use with it. Learn more about uberSVN and get a free
> download at:  http://p.sf.net/sfu/wandisco-dev2dev
>
> _______________________________________________
> libopendbx-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libopendbx-devel
> http://www.linuxnetworks.de/doc/index.php/OpenDBX
>
>


-- 
Mariano
http://marianopeck.wordpress.com

Re: [opendbx] [Pharo-users] DBXTypeNotSupoorted with Glorp

[Mariano M. P. <mar...@gm...>]

On Tue, Aug 16, 2011 at 10:24 AM, Norbert Sendetzky <
no...@li...> wrote:

> Hi Alain, Mariano
>
> > Yes, that is what is expected, but in the case of SQLite, the column
> > type changes to  SQLITE_NULL for nulls and that is a problem in
> > squeakdbx now. I think column datatype should not be stored in the
> > resultset in the case of sqlite. Other databases don't behave this
> > way (as far as I can remember), so, overriding moveNext for sqlite
> > would probably be fine.
>
> SQLite introduces a new data type SQLITE_NULL and unfortunately, the
> column type changes if NULL values occur - independent of what the real
> data type of the column is. In all other database libraries, this isn't
> the case.
>
>
>

Thanks Norbert. So, in summary our (SqueakDBX) usage of OpenDBX is correct.
Nevertheless, we could adapt the backend for Sqlite in SqueakDBX so that
"fixes" this problem.




> Norbert
>
>
>
> ------------------------------------------------------------------------------
> uberSVN's rich system and user administration capabilities and model
> configuration take the hassle out of deploying and managing Subversion and
> the tools developers use with it. Learn more about uberSVN and get a free
> download at:  http://p.sf.net/sfu/wandisco-dev2dev
> _______________________________________________
> libopendbx-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libopendbx-devel
> http://www.linuxnetworks.de/doc/index.php/OpenDBX
>



-- 
Mariano
http://marianopeck.wordpress.com

Re: [opendbx] [Pharo-users] DBXTypeNotSupoorted with Glorp

[Norbert S. <no...@li...>]

Hi Alain, Mariano

> Yes, that is what is expected, but in the case of SQLite, the column
> type changes to  SQLITE_NULL for nulls and that is a problem in
> squeakdbx now. I think column datatype should not be stored in the
> resultset in the case of sqlite. Other databases don't behave this
> way (as far as I can remember), so, overriding moveNext for sqlite
> would probably be fine.

SQLite introduces a new data type SQLITE_NULL and unfortunately, the 
column type changes if NULL values occur - independent of what the real 
data type of the column is. In all other database libraries, this isn't 
the case.


Norbert

Re: [opendbx] [Pharo-users] DBXTypeNotSupoorted with Glorp

[Alain R. <al...@fr...>]

Hi Mariano,
Yes, that is what is expected, but in the case of SQLite, the column type changes to  SQLITE_NULL for nulls and that is a problem in squeakdbx now.
I think column datatype should not be stored in the resultset in the case of sqlite.
Other databases don't behave this way (as far as I can remember), so, overriding moveNext for sqlite would probably be fine.

Cheers
Alain
  "Mariano Martinez Peck" <mar...@gm...> a écrit dans le message de news: CAA+-=mWHq6X9JGz-5qTyb3z5ZqdUwMwBV06B5AEZ=ivZ...@ma......
  And here: http://www.linuxnetworks.de/doc/index.php/OpenDBX/C_API/Usage

   I can read:

  "
  Processing results 
  After fetching a row, all values of this row are available for further processing, as well as their name, length and type - but the name and the type of a column won't change. Also the number of columns returned by odbx_column_count() is fixed for the whole result. 

int i;

for( i = 0; i < odbx_column_count( result ); i++ )
{
    fprintf( stdout, "Name: %s\n", odbx_column_name( result, i ) );
    fprintf( stdout, "Type: %d\n", odbx_column_type( result, i ) );
    fprintf( stdout, "Length: %d\n", odbx_field_length( result, i ) );
    fprintf( stdout, "Value: %s\n", odbx_field_value( result, i ) );
}

  Besides odbx_column_type() these functions don't return error codes. Instead, they return zero (odbx_field_length()) or NULL (odbx_column_name() and odbx_field_length()), but you shouldn't check for those because these values are also valid return values. 

  All numbers are returned as strings from the database regardless if they are integers or floats. If you want to do arithmetic operations, you have to convert them to their machine dependent binary representation first. 

  "


  On Mon, Aug 15, 2011 at 11:11 PM, Mariano Martinez Peck <mar...@gm...> wrote:




    On Mon, Aug 15, 2011 at 9:59 PM, Alain Rastoul <al...@fr...> wrote:

      Hi,
      I finally found that when called in C with the same api calls that those made by opendbx, sqlite correctly returns datatype of columns when fetching rows, the problem is clearly that the data type is stored in SQueakDBX column description for the resultset  the first time it fetches the first row.
      For sqlite, squeakdbx should call the sqlite api to retrieve column datatype for each row and each colum while fetching data.

    Hi Alain. I am reading this: http://www.linuxnetworks.de/doc/index.php/OpenDBX/C_API/odbx_column_type

    From SqueakDBX, we send odbx_column_type ONCE PER RESULTSET. 
    You can see this in #processNextResultSet:querySettings:  that for every resultset it sends  #processResultWithRows:resultHandle:querySettings:

    Now.... should we send odbx_column_type and friends ONCE PER RAW? As far as I can see, in other databases we don't need to do that. But maybe we are wrong and you are right. 
    Norbert?

    Anyway, if you want to give it a try to Sqlite, what about overwrite #moveNext:  in SqlitePlatform and do something to set the new type for every raw. 

    From what I can see, if the type depends on each raw and it should be asked for every raw, then a design change is needed so that we can move the description from the REsultSet to the Raw :)
          


      But it may have implications I don't know.  Perhaps squeakDbx could get only true object values (are rawValues really needed) ?.

    Well, it depends on the user needs. Now, a key point is what GLORP should use. 
     
      Or perhaps another solution would be to call the sqlite api if the stored datatype is UNKNOWN in column description ... (only for sqlite, but sounds like a bad trick)

    sounds like a hask, but if it works it is at least a valid workaround. 
     
      I am perplexed ...

      Any idea is welcome

      Cheers 
      Alain
        "Mariano Martinez Peck" <mar...@gm...> a écrit dans le message de news: CAA+-=mW69g-M...@pu......



        On Sat, Aug 13, 2011 at 12:06 AM, Alain Rastoul <al...@fr...> wrote:

          It doen't work.
          Howerver googling for opendbx msg00483, I found
          http://www.mail-archive.com/lib...@pu.../msg00483.html

        yes, that one :)
         
          it seems to be the problem of the issue 10, and I think the same problem I have..

        yes 
        Sorry, I cannot do more....  :(
         
          Strange that it doesn't work with MSSQL too..

            "Mariano Martinez Peck" <mar...@gm...> a écrit dans le message de news: CAA+-=mW4rwrLMhMAzsLhQ5zEWZBG_Jg=BF2dKu3wsxw0=io=iQ-JsoAwUIsXounXO2b/Sh...@pu...om...



            On Fri, Aug 12, 2011 at 11:14 PM, Alain Rastoul <al...@fr...> wrote:

              I used the following script (about  2 months ago I think ) in Pharo 1.3

              "SqueakDBX"
              Gofer new squeaksource: 'MetacelloRepository';
              package: 'ConfigurationOfSqueakDBX';
              load.
              ConfigurationOfSqueakDBX project latestVersion load.

              "GLORP"
              Gofer new squeaksource: 'MetacelloRepository';
              package: 'ConfigurationOfGlorpDBX';
              load.
              ConfigurationOfGlorpDBX project latestVersion load.



            Yes, you are using SqueakDBX ;)  you will move soon to DBXTalk :)
             
              II use DBXTestCase for my  test with the code I send in my email (is it ok for you?), but I will have alook at DBXQueryTest too.
              No problem to put it in the test suite - it makes me remember that I still didn't send my license agreement to Stephane but I will do it asap... I hate papers ;-)

            in our case we don't need that ;)
             
              http://www.mail-archive.com/lib...@pu.../msg00483.html
              The link is broken 


            http://www.mail-archive.com/lib...@pu.../msg00483.html 



            this one works?


            -- 
            Mariano
            http://marianopeck.wordpress.com





        -- 
        Mariano
        http://marianopeck.wordpress.com





    -- 
    Mariano
    http://marianopeck.wordpress.com





  -- 
  Mariano
  http://marianopeck.wordpress.com




------------------------------------------------------------------------------


  ------------------------------------------------------------------------------
  uberSVN's rich system and user administration capabilities and model 
  configuration take the hassle out of deploying and managing Subversion and 
  the tools developers use with it. Learn more about uberSVN and get a free 
  download at:  http://p.sf.net/sfu/wandisco-dev2dev



------------------------------------------------------------------------------

Re: [opendbx] [Pharo-users] DBXTypeNotSupoorted with Glorp

[Mariano M. P. <mar...@gm...>]

And here: http://www.linuxnetworks.de/doc/index.php/OpenDBX/C_API/Usage

 I can read:

" Processing results

After fetching a row, all values of this row are available for further
processing, as well as their name, length and type - but the name and the
type of a column won't change. Also the number of columns returned by
odbx_column_count<http://www.linuxnetworks.de/doc/index.php/OpenDBX/API/odbx_column_count>()
is fixed for the whole result.

int i;

for( i = 0; i < odbx_column_count( result ); i++ )
{
    fprintf( stdout, "Name: %s\n", odbx_column_name( result, i ) );
    fprintf( stdout, "Type: %d\n", odbx_column_type( result, i ) );
    fprintf( stdout, "Length: %d\n", odbx_field_length( result, i ) );
    fprintf( stdout, "Value: %s\n", odbx_field_value( result, i ) );
}


Besides odbx_column_type<http://www.linuxnetworks.de/doc/index.php/OpenDBX/API/odbx_column_type>()
these functions don't return error codes. Instead, they return zero (
odbx_field_length<http://www.linuxnetworks.de/doc/index.php/OpenDBX/API/odbx_field_length>())
or NULL (odbx_column_name<http://www.linuxnetworks.de/doc/index.php/OpenDBX/API/odbx_column_name>()
and odbx_field_length<http://www.linuxnetworks.de/doc/index.php/OpenDBX/API/odbx_field_length>()),
but you shouldn't check for those because these values are also valid return
values.

All numbers are returned as strings from the database regardless if they are
integers or floats. If you want to do arithmetic operations, you have to
convert them to their machine dependent binary representation first.
"

On Mon, Aug 15, 2011 at 11:11 PM, Mariano Martinez Peck <
mar...@gm...> wrote:

>
>
> On Mon, Aug 15, 2011 at 9:59 PM, Alain Rastoul <al...@fr...> wrote:
>
>> **
>> Hi,
>> I finally found that when called in C with the same api calls that those
>> made by opendbx, sqlite correctly returns datatype of columns when fetching
>> rows, the problem is clearly that the data type is stored in SQueakDBX
>> column description for the resultset  the first time it fetches the first
>> row.
>> For sqlite, squeakdbx should call the sqlite api to retrieve column
>> datatype for each row and each colum while fetching data.
>>
>
> Hi Alain. I am reading this:
> http://www.linuxnetworks.de/doc/index.php/OpenDBX/C_API/odbx_column_type
>
> From SqueakDBX, we send odbx_column_type ONCE PER RESULTSET.
> You can see this in #processNextResultSet:querySettings:  that for every
> resultset it sends  #processResultWithRows:resultHandle:querySettings:
>
> Now.... should we send odbx_column_type and friends ONCE PER RAW? As far as
> I can see, in other databases we don't need to do that. But maybe we are
> wrong and you are right.
> Norbert?
>
> Anyway, if you want to give it a try to Sqlite, what about overwrite
> #moveNext:  in SqlitePlatform and do something to set the new type for every
> raw.
>
> From what I can see, if the type depends on each raw and it should be asked
> for every raw, then a design change is needed so that we can move the
> description from the REsultSet to the Raw :)
>
>
> But it may have implications I don't know.  Perhaps squeakDbx could get
>> only true object values (are rawValues really needed) ?.
>>
>
> Well, it depends on the user needs. Now, a key point is what GLORP should
> use.
>
>
>>  Or perhaps another solution would be to call the sqlite api if the
>> stored datatype is UNKNOWN in column description ... (only for sqlite,
>> but sounds like a bad trick)
>>
>
> sounds like a hask, but if it works it is at least a valid workaround.
>
>
>>  I am perplexed ...
>>
>> Any idea is welcome
>>
>> Cheers
>> Alain
>>
>> "Mariano Martinez Peck" <mar...@gm...> a écrit dans le message
>> de news:
>> CAA+-=mW6...@ma......
>>
>>
>> On Sat, Aug 13, 2011 at 12:06 AM, Alain Rastoul <al...@fr...> wrote:
>>
>>> **
>>> It doen't work.
>>> Howerver googling for opendbx msg00483, I found
>>>
>>> http://www.mail-archive.com/lib...@pu.../msg00483.html<http://www.mail-archive.com/lib...@pu.../msg00483.html>
>>>
>>
>> yes, that one :)
>>
>>
>>>  it seems to be the problem of the issue 10, and I think the same
>>> problem I have..
>>>
>>
>> yes
>> Sorry, I cannot do more....  :(
>>
>>
>>>  Strange that it doesn't work with MSSQL too..
>>>
>>>
>>> "Mariano Martinez Peck" <mar...@gm...> a écrit dans le message
>>> de news:
>>> CAA+-=mW4rwrLMhMAzsLhQ5zEWZBG_Jg=BF2dKu3wsxw0=io=iQ...@ma......
>>>
>>>
>>> On Fri, Aug 12, 2011 at 11:14 PM, Alain Rastoul <al...@fr...> wrote:
>>>
>>>> **
>>>> I used the following script (about  2 months ago I think ) in Pharo 1.3
>>>> "SqueakDBX"
>>>> Gofer new squeaksource: 'MetacelloRepository';
>>>> package: 'ConfigurationOfSqueakDBX';
>>>> load.
>>>> ConfigurationOfSqueakDBX project latestVersion load.
>>>>
>>>> "GLORP"
>>>> Gofer new squeaksource: 'MetacelloRepository';
>>>> package: 'ConfigurationOfGlorpDBX';
>>>> load.
>>>> ConfigurationOfGlorpDBX project latestVersion load.
>>>>
>>>>
>>> Yes, you are using SqueakDBX ;)  you will move soon to DBXTalk :)
>>>
>>>
>>>>  II use DBXTestCase for my  test with the code I send in my email (is
>>>> it ok for you?), but I will have alook at DBXQueryTest too.
>>>> No problem to put it in the test suite - it makes me remember that I
>>>> still didn't send my license agreement to Stephane but I will do it
>>>> asap... I hate papers ;-)
>>>>
>>>
>>> in our case we don't need that ;)
>>>
>>>
>>>>
>>>> http://www.mail-archive.com/lib...@pu.../msg00483.html
>>>> The link is broken
>>>>
>>>
>>>
>>> http://www.mail-archive.com/lib...@pu.../msg00483.html
>>>
>>> this one works?
>>>
>>>
>>> --
>>> Mariano
>>> http://marianopeck.wordpress.com
>>>
>>>
>>
>>
>> --
>> Mariano
>> http://marianopeck.wordpress.com
>>
>>
>
>
> --
> Mariano
> http://marianopeck.wordpress.com
>
>


-- 
Mariano
http://marianopeck.wordpress.com

Re: [opendbx] [Pharo-users] DBXTypeNotSupoorted with Glorp

[Mariano M. P. <mar...@gm...>]

On Mon, Aug 15, 2011 at 9:59 PM, Alain Rastoul <al...@fr...> wrote:

> **
> Hi,
> I finally found that when called in C with the same api calls that those
> made by opendbx, sqlite correctly returns datatype of columns when fetching
> rows, the problem is clearly that the data type is stored in SQueakDBX
> column description for the resultset  the first time it fetches the first
> row.
> For sqlite, squeakdbx should call the sqlite api to retrieve column
> datatype for each row and each colum while fetching data.
>

Hi Alain. I am reading this:
http://www.linuxnetworks.de/doc/index.php/OpenDBX/C_API/odbx_column_type

>From SqueakDBX, we send odbx_column_type ONCE PER RESULTSET.
You can see this in #processNextResultSet:querySettings:  that for every
resultset it sends  #processResultWithRows:resultHandle:querySettings:

Now.... should we send odbx_column_type and friends ONCE PER RAW? As far as
I can see, in other databases we don't need to do that. But maybe we are
wrong and you are right.
Norbert?

Anyway, if you want to give it a try to Sqlite, what about overwrite
#moveNext:  in SqlitePlatform and do something to set the new type for every
raw.

>From what I can see, if the type depends on each raw and it should be asked
for every raw, then a design change is needed so that we can move the
description from the REsultSet to the Raw :)


But it may have implications I don't know.  Perhaps squeakDbx could get only
> true object values (are rawValues really needed) ?.
>

Well, it depends on the user needs. Now, a key point is what GLORP should
use.


> Or perhaps another solution would be to call the sqlite api if the stored
> datatype is UNKNOWN in column description ... (only for sqlite, but sounds
> like a bad trick)
>

sounds like a hask, but if it works it is at least a valid workaround.


> I am perplexed ...
>
> Any idea is welcome
>
> Cheers
> Alain
>
> "Mariano Martinez Peck" <mar...@gm...> a écrit dans le message de
> news: CAA+-=mW6...@ma...
> ...
>
>
> On Sat, Aug 13, 2011 at 12:06 AM, Alain Rastoul <al...@fr...> wrote:
>
>> **
>> It doen't work.
>> Howerver googling for opendbx msg00483, I found
>>
>> http://www.mail-archive.com/lib...@pu.../msg00483.html<http://www.mail-archive.com/lib...@pu.../msg00483.html>
>>
>
> yes, that one :)
>
>
>>  it seems to be the problem of the issue 10, and I think the same problem
>> I have..
>>
>
> yes
> Sorry, I cannot do more....  :(
>
>
>>  Strange that it doesn't work with MSSQL too..
>>
>>
>> "Mariano Martinez Peck" <mar...@gm...> a écrit dans le message
>> de news:
>> CAA+-=mW4rwrLMhMAzsLhQ5zEWZBG_Jg=BF2dKu3wsxw0=io=iQ...@ma......
>>
>>
>> On Fri, Aug 12, 2011 at 11:14 PM, Alain Rastoul <al...@fr...> wrote:
>>
>>> **
>>> I used the following script (about  2 months ago I think ) in Pharo 1.3
>>> "SqueakDBX"
>>> Gofer new squeaksource: 'MetacelloRepository';
>>> package: 'ConfigurationOfSqueakDBX';
>>> load.
>>> ConfigurationOfSqueakDBX project latestVersion load.
>>>
>>> "GLORP"
>>> Gofer new squeaksource: 'MetacelloRepository';
>>> package: 'ConfigurationOfGlorpDBX';
>>> load.
>>> ConfigurationOfGlorpDBX project latestVersion load.
>>>
>>>
>> Yes, you are using SqueakDBX ;)  you will move soon to DBXTalk :)
>>
>>
>>>  II use DBXTestCase for my  test with the code I send in my email (is it
>>> ok for you?), but I will have alook at DBXQueryTest too.
>>> No problem to put it in the test suite - it makes me remember that I
>>> still didn't send my license agreement to Stephane but I will do it
>>> asap... I hate papers ;-)
>>>
>>
>> in our case we don't need that ;)
>>
>>
>>>
>>> http://www.mail-archive.com/lib...@pu.../msg00483.html
>>> The link is broken
>>>
>>
>>
>> http://www.mail-archive.com/lib...@pu.../msg00483.html
>>
>> this one works?
>>
>>
>> --
>> Mariano
>> http://marianopeck.wordpress.com
>>
>>
>
>
> --
> Mariano
> http://marianopeck.wordpress.com
>
>


-- 
Mariano
http://marianopeck.wordpress.com