sqlrelay-discussion — Discussion of topics related to SQL Relay

Re: [Sqlrelay-discussion] SQLRelay and large numbers in Oracle (other databases too?)

[<mac...@co...>]

>Those sound like good possible solutions.  I'll look into it a bit and
>see what I can come up with.  Hopefully I'll get something in place for
>0.38.
>
Any news on this problem? When can we expect release of 0.38?

-- 
Maciej Wisniowski

[Sqlrelay-discussion] error compiling, FC 5, mysql 5.1

[Ricardo K. <ri...@am...>]

Hi,

I have Fedora 5, and the mysql rpms I've installed are the ones for 5.1 =
straight from mysql.com

When I try to compile, I get the errors:

g++: /usr/lib/mysql/libmysqlclient.so: No such file or directory
g++: /usr/lib/mysql/libz.so: No such file or directory
make[3]: *** [sqlr-connection-mysql] Error 1
make[3]: Leaving directory =
`/root/builds/sqlrelay-0.37/src/connections/mysql'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/root/builds/sqlrelay-0.37/src/connections'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/root/builds/sqlrelay-0.37/src'
make: *** [all] Error 2

Here's what I have in /usr/lib/mysql:

[root@db_mgr sqlrelay-0.37]# ls /usr/lib/mysql
libdbug.a       libmysqlclient.a     libmystrings.a   libvio.a
libheap.a       libmysqlclient.la    libmysys.a       libz.a
libmyisam.a     libmysqlclient_r.a   libndbclient.a   libz.la
libmyisammrg.a  libmysqlclient_r.la  libndbclient.la  mysqld-max.sym

So I have libmysqlclient.a and libz.a but I don't have the .so =
versions... would a simple symlink work?

Ricardo

[Sqlrelay-discussion] a bug exists in the rudiments

[seong h. p. <seo...@gm...>]

In the file src/inetclientsocket.C:145

 do {
                        result=getaddrinfo(_address(),portstr,&hints,&ai);
                } while (result==-1 && error::getErrorNumber()==EINTR);
                delete[] portstr;
                if (result==-1) {
                        return RESULT_ERROR;
                }

but return value of getaddraddrinfo() is not only -1 if failed

line 196:
for (addrinfo *ainfo=ai; ainfo; ainfo=ainfo->ai_next) {

If target hostname doesn't exists ( in my system, getaddrinfo() returns -2)
segmentation fault can occur here as it haven't returned with RESULT_ERROR
( I build it with efence library)

[Sqlrelay-discussion] Error Codes form SQLRelay into PHP

[Dave S. <dsu...@co...>]

Hi,

I have been doing some repurposing of some PHP code to use SQLRelay  
instead of the PEAR oci8 interface.  And all is generally pretty  
good, but I have noticed some cases were we are checking for specific  
error conditions returned from the database and those conditions are  
not being met when using SQLRelay.

An example of this is a case where we perform an insert and expect  
that we might get back the error DB_ERROR_ALREADY_EXISTS if the  
insert fails because the row already exists.  But SQLRelay doesn't  
seem to care what the error is, it just returns the generic error  
DB_ERROR.  Is there a way to get SQLRelay to know more information  
about the error that has been returned?

We are using SQLRelay 0.37 which I believe is the latest.

Thanks
Dave Sugar
dsu...@co...

Re: [Sqlrelay-discussion] Glibc error with Java API

[Rodrigo P. T. <te...@de...>]

Hi David,

Thanks for your answer!
By the way we solved the problem. Looks like the problem is happening
because
we are using an static connection between our Java APP and SQLRelay or
so the
Java APP reuses the same SQLRelay connection each time (running as a daem=
on)
it needs to connect to DB backend and the connection is never closed
(destroyed).
We change our Java APP to close/destroy the connection to SQLRelay after
each
task (some SQL queries) and the problem disappeared completely!

The problem is happening (using an static connection) with any kind of
queries but
just to give you examples:

Query 1:
SELECT RadAcctId, AcctSessionId, AcctUniqueId, UserName, Realm,
NASIPAddress, NASPortId, NASPortType, AcctStartTime, Acct
StopTime, AcctSessionTime, AcctAuthentic, ConnectInfo_start,
ConnectInfo_stop, AcctInputOctets, AcctOutputOctets, CalledStationId,
CallingStationId, AcctTerminateCause, ServiceType, FramedProtocol,
FramedIPAddress, AcctStartDelay, AcctStopDelay FROM radacct WHERE
AcctSessionId=3D'c5d10af3-cfb8f381@192.168.1.100' AND ConnectInfo_start =3D=

'1e0744b4f44da09o1' AND ConnectInfo_stop =3D 'as2ccc0688' AND
AcctTerminateCause =3D '200'

Query 2:
Update acc_relay set status =3D '0' where id =3D 10


Thanks for your prompt help!

Telles


David Muse wrote:
> I think I remember someone reporting this before, maybe you :)
>
> Those errors generally occur when there's a double free or an
> uninitialized variable.  I'll look through the code for something like
> that, but if you can narrow down which queries cause the crash, it'll b=
e
> a lot easier to figure out.
>
> Dave
> dav...@fi...
>
>
> On Mon, 2006-07-24 at 16:19 -0300, Rodrigo P. Telles wrote:
>  =20
>> Hi Folks,
>>
>> I'm facing some errors using SQLRelay 0.36.4 with Java API as listed b=
elow.
>> I tried to update to the latest SQLRelay version (0.37) but nothing ch=
anges the error still happening.
>> When that error happens the Java App is killed!
>>
>> 2006-07-24 15:31:57.535476500 *** glibc detected *** free(): invalid
>> next size (fast): 0x08069680 ***
>>
>> 2006-07-24 15:20:53.190113500 *** glibc detected *** free(): invalid
>> next size (fast): 0x0806e300 ***
>>
>> 2006-07-24 15:19:07.109816500 *** glibc detected *** free(): invalid
>> next size (fast): 0x080b5f18 ***
>>
>> 2006-07-24 14:55:28.414175500 *** glibc detected *** free(): invalid
>> next size (fast): 0x08105270 ***
>>
>> 2006-07-24 14:53:42.518603500 *** glibc detected *** free(): invalid
>> next size (fast): 0x08106058 ***
>>
>> 2006-07-24 14:53:12.011833500 *** glibc detected *** free(): invalid
>> pointer: 0x08133558 ***
>>
>> 2006-07-24 14:51:10.687502500 *** glibc detected *** malloc(): memory
>> corruption: 0x08128c28 ***
>>
>> 2006-07-24 14:50:25.076671500 *** glibc detected *** free(): invalid
>> next size (fast): 0x080f5738 ***
>>
>> 2006-07-24 14:48:39.040298500 *** glibc detected *** free(): invalid
>> pointer: 0x08133468 ***
>>
>> 2006-07-24 14:47:53.374118500 *** glibc detected *** free(): invalid
>> next size (fast): 0x08139610 ***
>>
>> 2006-07-24 14:47:07.763850500 *** glibc detected *** free(): invalid
>> pointer: 0x08167e98 ***
>>
>> 2006-07-24 14:44:21.419332500 *** glibc detected *** free(): invalid
>> next size (fast): 0x08128440 ***
>>
>> 2006-07-24 14:43:20.713662500 *** glibc detected *** corrupted
>> double-linked list: 0x08139608 ***
>>
>> 2006-07-24 14:37:17.769239500 *** glibc detected *** free(): invalid
>> next size (fast): 0x0806bef0 ***
>>
>> 2006-07-24 14:29:14.538502500 *** glibc detected *** free(): invalid
>> next size (fast): 0x080f8918 ***
>>
>>
>> Its happening on some (random) SGBD operations (select, update, delete=
, etc).
>>
>> Informations about O.S.:
>> Mandriva 2006 Kernel 2.6.12-12mdk
>> glibc-2.3.5-5mdk
>> gcc-4.0.1-5mdk
>> gcc-c++-4.0.1-5mdk
>>
>> Looks like there is some memory leak on SQLRelay.
>> Thanks for any help!
>>
>> Telles
>>
>>    =20

Re: [Sqlrelay-discussion] SIGSEGV when trying to create temporary table

[Devananda <kar...@ya...>]

David Muse wrote:
> Ever figure out anything out on this?

Push the responsibility onto the application :)

Not a real solution, but a quick one, and afaiac, it's not 
objectionable. Applications, and their programmers, shouldn't rely on a 
framework or connection method to clean up after them (though it is nice 
when they do).

I made a stub for checkForTempTable function in mysqlconnection.C 
(simply "return;"), and told the application developers here that they 
/must/ clean up their own temp tables. Since I sign off on all their SQL 
statements, I'll be able to ensure that they do.

Regards,
Devananda



> 
> Dave
> dav...@fi...
> 
> On Fri, 2006-07-07 at 13:14 -0700, Devananda wrote:
>> When sending CREATE TEMPORARY TABLE... either from PHP, or through 
>> sqlrhsh, the sqlr-connection segfaults. I ran the connection process in 
>> gdb, and received the following info:
>>
>> Program received signal SIGSEGV, Segmentation fault.
>> [Switching to Thread 2596304 (LWP 4296)]
>> 0x0093fa39 in sqlrcursor_svr::checkForTempTable ()
>>    from /usr/local/firstworks/lib/libsqlrconnection_debug-0.37.so.1
>>
>> The version of sql relay in which this happened is a slightly old 0.37, 
>> connecting to both MySQL 4.1.18 and 5.0.22 (the segfault happens with 
>> both connections). I will attempt to verify that this affects the latest 
>> sqlrelay (pulled from CVS) as soon as I can hammer out a library issue 
>> (probably early next week).
>>
>>
>> Regards,
>> Devananda vdv
>>
>> Using Tomcat but need to do more? Need to support web services, security?
>> Get stuff done quickly with pre-integrated technology to make your job easier
>> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>> _______________________________________________
>> Sqlrelay-discussion mailing list
>> Sql...@li...
>> https://lists.sourceforge.net/lists/listinfo/sqlrelay-discussion
>>
> 
> 

Re: [Sqlrelay-discussion] Glibc error with Java API

[Ionut C. <ion...@av...>]

No, it was me. It was happenning with an oracle back-end and php API, when
fetching clobs containing unicode characters.

I attached the old e-mail I sent initially. Last time I tested on 0.37
stable it was still happenning.

Note that in that old e-mail I said it wasn't happenning in 0.34. What we
later discovered however was that there was no segfault (and no obvious
memory leak), but the unicode chars and large fragments of text around them
got silently truncated.

Regards,
Ionut

----- Original Message ----- 
From: "David Muse" <dav...@fi...>
To: "Discussion of topics related to SQL Relay"
<sql...@li...>
Sent: Wednesday, July 26, 2006 6:04 AM
Subject: Re: [Sqlrelay-discussion] Glibc error with Java API


|I think I remember someone reporting this before, maybe you :)
|
| Those errors generally occur when there's a double free or an
| uninitialized variable.  I'll look through the code for something like
| that, but if you can narrow down which queries cause the crash, it'll be
| a lot easier to figure out.
|
| Dave
| dav...@fi...
|
|
| On Mon, 2006-07-24 at 16:19 -0300, Rodrigo P. Telles wrote:
| > Hi Folks,
| >
| > I'm facing some errors using SQLRelay 0.36.4 with Java API as listed
below.
| > I tried to update to the latest SQLRelay version (0.37) but nothing
changes the error still happening.
| > When that error happens the Java App is killed!
| >
| > 2006-07-24 15:31:57.535476500 *** glibc detected *** free(): invalid
| > next size (fast): 0x08069680 ***
| >
| > 2006-07-24 15:20:53.190113500 *** glibc detected *** free(): invalid
| > next size (fast): 0x0806e300 ***
| >
| > 2006-07-24 15:19:07.109816500 *** glibc detected *** free(): invalid
| > next size (fast): 0x080b5f18 ***
| >
| > 2006-07-24 14:55:28.414175500 *** glibc detected *** free(): invalid
| > next size (fast): 0x08105270 ***
| >
| > 2006-07-24 14:53:42.518603500 *** glibc detected *** free(): invalid
| > next size (fast): 0x08106058 ***
| >
| > 2006-07-24 14:53:12.011833500 *** glibc detected *** free(): invalid
| > pointer: 0x08133558 ***
| >
| > 2006-07-24 14:51:10.687502500 *** glibc detected *** malloc(): memory
| > corruption: 0x08128c28 ***
| >
| > 2006-07-24 14:50:25.076671500 *** glibc detected *** free(): invalid
| > next size (fast): 0x080f5738 ***
| >
| > 2006-07-24 14:48:39.040298500 *** glibc detected *** free(): invalid
| > pointer: 0x08133468 ***
| >
| > 2006-07-24 14:47:53.374118500 *** glibc detected *** free(): invalid
| > next size (fast): 0x08139610 ***
| >
| > 2006-07-24 14:47:07.763850500 *** glibc detected *** free(): invalid
| > pointer: 0x08167e98 ***
| >
| > 2006-07-24 14:44:21.419332500 *** glibc detected *** free(): invalid
| > next size (fast): 0x08128440 ***
| >
| > 2006-07-24 14:43:20.713662500 *** glibc detected *** corrupted
| > double-linked list: 0x08139608 ***
| >
| > 2006-07-24 14:37:17.769239500 *** glibc detected *** free(): invalid
| > next size (fast): 0x0806bef0 ***
| >
| > 2006-07-24 14:29:14.538502500 *** glibc detected *** free(): invalid
| > next size (fast): 0x080f8918 ***
| >
| >
| > Its happening on some (random) SGBD operations (select, update, delete,
etc).
| >
| > Informations about O.S.:
| > Mandriva 2006 Kernel 2.6.12-12mdk
| > glibc-2.3.5-5mdk
| > gcc-4.0.1-5mdk
| > gcc-c++-4.0.1-5mdk
| >
| > Looks like there is some memory leak on SQLRelay.
| > Thanks for any help!
| >
| > Telles
| >
| >
| >
|
> -------------------------------------------------------------------------
| > Take Surveys. Earn Cash. Influence the Future of IT
| > Join SourceForge.net's Techsay panel and you'll get the chance to share
your
| > opinions on IT & business topics through brief surveys -- and earn cash
| >
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
| > _______________________________________________
| > Sqlrelay-discussion mailing list
| > Sql...@li...
| > https://lists.sourceforge.net/lists/listinfo/sqlrelay-discussion
| >
|
|
| -------------------------------------------------------------------------
| Take Surveys. Earn Cash. Influence the Future of IT
| Join SourceForge.net's Techsay panel and you'll get the chance to share
your
| opinions on IT & business topics through brief surveys -- and earn cash
| http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
| _______________________________________________
| Sqlrelay-discussion mailing list
| Sql...@li...
| https://lists.sourceforge.net/lists/listinfo/sqlrelay-discussion

[Sqlrelay-discussion] problems selecting BLOB data

[Devananda <kar...@ya...>]

I've been trying different methods of inserting and selecting BLOB data 
  through the PHP API from a MySQL 5.0.18 server, so far with mixed 
results. I'd like to be able to use prepared statements with stored 
procedures, but unfortunately, MySQL does not yet support that.

So... What I've found is that inserting binary data through a prepared 
statement works very well, regardless of the size of the data. After 
changing mysqld's max_allowed_packet setting, I was able to insert a 
~20M blob. However, reading binary data fails with large objects (100k 
or so), but works successfully with smaller objects.

I have tried adjusting the 'maxquerysize', 'maxstringbindvaluelength', 
and 'maxlobbindvaluelength' configuration options in sqlrelay, to no 
effect. (AFAIK, these params only affect statements coming from the API, 
and do not pertain to result sets.)

Something I find particularly telling is that, within the debug output 
of the sqlr-connection, I see "actual rows: 1" ... "fetching 0 rows". 
(I've pasted the debug output stream below.)

I've looked in the api, connection, and cursor header files, but did not 
see any defines that seemed to pertain to this. Any suggestions where to 
look, or how to fix, or if I'm doing something wrong?

Thanks,
Devananda vdv


> getting command...
>  done getting command
>  getting a cursor...
>  done getting a cursor
>  new query
>  handling query...
>  getting query...
>  querylength:
>  42
>  query:
>      SELECT v FROM test.blob_test WHERE k=3
>  getting query succeeded
>  getting input binds...
>  done getting input binds
>  getting output binds...
>  done getting output binds
>  getting send column info...
>  send column info
>  done getting send column info...
>  processing query...
>  preparing/executing...
>  preparing query...
>  done preparing query
>  handling binds...
>  done handling binds
>  executing query...
>  done executing query
>  commit or rollback check...
>  done with commit or rollback check
>  processing query succeeded
>  done processing query
>  returning result set header...
>  returning row counts...
>  sending row counts...
>  actual rows: 1
>  affected rows: -1
>  done sending row counts
>  done returning row counts
>  column info will be sent
>  returning column counts...
>  done returning column counts
>  sending column type format...
>  id's
>  done sending column type format
>  returning column info...
>  v:45:2147483647 (-1,0) NOT NULL
>  done returning column info
>  returning output bind values
>  0
>  done returning output bind values
>  done returning result set header
>  handle query succeeded
>  returning result set data...
>  skipping 0 rows...
>  done skipping rows
>  fetching 0 rows...
>  done returning result set data

Re: [Sqlrelay-discussion] infinite loop

[David M. <dav...@fi...>]

I ran into a similar problem a while back.  The mysql api does
erroneously return a db has gone away error when certain queries are
run.  I believe in some cases, a query returns multiple result sets and
the code has to decide which one to use, and the first one has that
error in it, or something like that.  I think I ran into the issue when
trying to get stored functions working.  There were lots of references
to similar problems on the web.  I haven't come up with a good solution
yet, but it's on my list :/

Dave
dav...@fi...

On Sat, 2006-07-22 at 10:04 -0700, Devananda wrote:
> Dear List,
> 
> sqlrelay is regularly getting stuck in an infinite reconnect loop on 
> both servers on which I am running it right now. This seems to happen 
> /most often/ after hours of inactivity, but not always. I've spent a 
> week tracking this down, and have found where the MySQL C API is 
> returning an unexpected result, and sqlrelay goes into an infinite loop 
> because of it.
> 
> First, the platform; sqlrelay pulled from CVS a few weeks ago, Fedora 
> 4/5, and MySQL 5.0.18-5.0.22.
> 
> The loop itself happens inside the sqlrconnection_svr::handleQuery 
> function, where the inline comments clearly state "loop here to handle 
> down databases" :) The problem is that the MySQL C API (erroneously?) 
> returns an error message (CR_SERVER_GONE_ERROR) at mysqlconnection.C:542
> 
> if ((queryresult=mysql_stmt_execute(stmt))) {
> 
> As a result, sqlrconnection_svr::processQuery returns FALSE, which 
> triggers sqlrconnection_svr::handleError, which can not returnError() 
> because the database appears to be down, and therefor calls reLogIn(). 
> However, the database is not actually down, and sqlrelay reconnects to 
> it easily, tries to rerun the initial query, and gets the same return 
> value of CR_SERVER_GONE_ERROR, thus beginning the loop again.
> 
> Running sqlr-status during this time shows number of connections 
> skyrocketing, and asking MySQL to "SHOW STATUS" shows the number of 
> client connections (Aborted_clients and Connections) to be increasing as 
> well. "SHOW PROCESSLIST" also displays sqlrelay's connections, which are 
> being established and closed as fast as the server is able.
> 
> This looks as though it could be caused by the bug reported at 
> http://bugs.mysql.com/bug.php?id=19927.
> 
> I have added some code to detect and break out of the infinite loop, 
> hoping that would patch sqlrelay while MySQL fixes their bugs, however, 
> simply breaking out of the loop does not sufficiently fix what ever is 
> wrong. Any further debugging is beyond my abilities :(
> 
> If anyone can help, it would be very appreciated. We are on a pretty 
> tight development schedule, and this is really slowing us down. If 
> anyone needs to see a sqlrelay debug file, let me know and I'll send it 
> off-list.
> 
> 
> 
> Best Regards,
> Devananda van der Veen
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Sqlrelay-discussion mailing list
> Sql...@li...
> https://lists.sourceforge.net/lists/listinfo/sqlrelay-discussion
> 

Re: [Sqlrelay-discussion] Glibc error with Java API

[David M. <dav...@fi...>]

I think I remember someone reporting this before, maybe you :)

Those errors generally occur when there's a double free or an
uninitialized variable.  I'll look through the code for something like
that, but if you can narrow down which queries cause the crash, it'll be
a lot easier to figure out.

Dave
dav...@fi...


On Mon, 2006-07-24 at 16:19 -0300, Rodrigo P. Telles wrote:
> Hi Folks,
> 
> I'm facing some errors using SQLRelay 0.36.4 with Java API as listed below.
> I tried to update to the latest SQLRelay version (0.37) but nothing changes the error still happening.
> When that error happens the Java App is killed!
> 
> 2006-07-24 15:31:57.535476500 *** glibc detected *** free(): invalid
> next size (fast): 0x08069680 ***
> 
> 2006-07-24 15:20:53.190113500 *** glibc detected *** free(): invalid
> next size (fast): 0x0806e300 ***
> 
> 2006-07-24 15:19:07.109816500 *** glibc detected *** free(): invalid
> next size (fast): 0x080b5f18 ***
> 
> 2006-07-24 14:55:28.414175500 *** glibc detected *** free(): invalid
> next size (fast): 0x08105270 ***
> 
> 2006-07-24 14:53:42.518603500 *** glibc detected *** free(): invalid
> next size (fast): 0x08106058 ***
> 
> 2006-07-24 14:53:12.011833500 *** glibc detected *** free(): invalid
> pointer: 0x08133558 ***
> 
> 2006-07-24 14:51:10.687502500 *** glibc detected *** malloc(): memory
> corruption: 0x08128c28 ***
> 
> 2006-07-24 14:50:25.076671500 *** glibc detected *** free(): invalid
> next size (fast): 0x080f5738 ***
> 
> 2006-07-24 14:48:39.040298500 *** glibc detected *** free(): invalid
> pointer: 0x08133468 ***
> 
> 2006-07-24 14:47:53.374118500 *** glibc detected *** free(): invalid
> next size (fast): 0x08139610 ***
> 
> 2006-07-24 14:47:07.763850500 *** glibc detected *** free(): invalid
> pointer: 0x08167e98 ***
> 
> 2006-07-24 14:44:21.419332500 *** glibc detected *** free(): invalid
> next size (fast): 0x08128440 ***
> 
> 2006-07-24 14:43:20.713662500 *** glibc detected *** corrupted
> double-linked list: 0x08139608 ***
> 
> 2006-07-24 14:37:17.769239500 *** glibc detected *** free(): invalid
> next size (fast): 0x0806bef0 ***
> 
> 2006-07-24 14:29:14.538502500 *** glibc detected *** free(): invalid
> next size (fast): 0x080f8918 ***
> 
> 
> Its happening on some (random) SGBD operations (select, update, delete, etc).
> 
> Informations about O.S.:
> Mandriva 2006 Kernel 2.6.12-12mdk
> glibc-2.3.5-5mdk
> gcc-4.0.1-5mdk
> gcc-c++-4.0.1-5mdk
> 
> Looks like there is some memory leak on SQLRelay.
> Thanks for any help!
> 
> Telles
> 
> 
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Sqlrelay-discussion mailing list
> Sql...@li...
> https://lists.sourceforge.net/lists/listinfo/sqlrelay-discussion
> 

Re: [Sqlrelay-discussion] SIGSEGV when trying to create temporary table

[David M. <dav...@fi...>]

Ever figure out anything out on this?

Dave
dav...@fi...

On Fri, 2006-07-07 at 13:14 -0700, Devananda wrote:
> When sending CREATE TEMPORARY TABLE... either from PHP, or through 
> sqlrhsh, the sqlr-connection segfaults. I ran the connection process in 
> gdb, and received the following info:
> 
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 2596304 (LWP 4296)]
> 0x0093fa39 in sqlrcursor_svr::checkForTempTable ()
>    from /usr/local/firstworks/lib/libsqlrconnection_debug-0.37.so.1
> 
> The version of sql relay in which this happened is a slightly old 0.37, 
> connecting to both MySQL 4.1.18 and 5.0.22 (the segfault happens with 
> both connections). I will attempt to verify that this affects the latest 
> sqlrelay (pulled from CVS) as soon as I can hammer out a library issue 
> (probably early next week).
> 
> 
> Regards,
> Devananda vdv
> 
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Sqlrelay-discussion mailing list
> Sql...@li...
> https://lists.sourceforge.net/lists/listinfo/sqlrelay-discussion
> 

Re: [Sqlrelay-discussion] What are cursors and how many do I need?

[David M. <dav...@fi...>]

Yes, cursors="38" means that each connection to the database will open
38 cursors, each of which has a pretty large buffer for processing
result sets.  SQL Relay doesn't impose any limit for the number of
cursors, but it's possible that more than 38 cursors is using up too
much ram, or that the database is running out of resources and
terminating the connection.

Dave
dav...@fi...

On Mon, 2006-07-24 at 19:54 -0700, Stephen Carville wrote:
> For anyone who might search for this issue, it looks like "cursors" is a 
> per connection specification and there is a limit of 38 per connection. 
>   At least sqlrelay (0.37) terminates the connection if I try to specify 
> more.
> 
> Stephen Carville wrote:
> > I'm new to using sqlrelay to connect to an Oracle 10g database and this 
> > is the first day in full production.  Every once in a while I get a 
> > strange error that looks like I have a connection to an instance but I 
> > canno toproicess any SQL.  From the log generated by DBI:
> > 
> >      -> prepare for DBD::SQLRelay::db (DBI::db=HASH(0x8e24758)~0x8e24a88 
> > 'select
> > 1 from dual') thr#8a610081
> >      <- FETCH= ( SQLRelay::Connection=SCALAR(0x8e24c08) ) [1 items] 
> > ('driver_connection' from cache) at SQLRelay.pm line 138
> >      -> STORE for DBD::SQLRelay::st (DBI::st=HASH(0x8e24b78)~0x9179278 
> > 'driver_database_handle' DBI::db=HASH(0x8e24a88)) thr#8a61008
> >      <- STORE= 1 at SQLRelay.pm line 145
> >      -> STORE for DBD::SQLRelay::st (DBI::st=HASH(0x8e24b78)~0x9179278 
> > 'NUM_OF_PARAMS' 0) thr#8a61008
> >      <- STORE= 1 at SQLRelay.pm line 146
> >      -> STORE for DBD::SQLRelay::st (DBI::st=HASH(0x8e24b78)~0x9179278 
> > 'driver_is_select' 1) thr#8a61008
> >      <- STORE= 1 at SQLRelay.pm line 147
> >      -> STORE for DBD::SQLRelay::st (DBI::st=HASH(0x8e24b78)~0x9179278 
> > 'driver_cursor' SQLRelay::Cursor=SCALAR(0x8e24cf8)) thr#8a61008
> >      <- STORE= 1 at SQLRelay.pm line 148
> >      -> STORE for DBD::SQLRelay::st (DBI::st=HASH(0x8e24b78)~0x9179278 
> > 'NUM_OF_PARAMS' 0) thr#8a61008
> >      <- STORE= 1 at SQLRelay.pm line 158
> >      <- prepare= DBI::st=HASH(0x8e24b78) at sql.pm line 185
> >      -> execute for DBD::SQLRelay::st 
> > (DBI::st=HASH(0x8e24b78)~0x9179278) thr#8a610081
> > <- FETCH= SQLRelay::Cursor=SCALAR(0x8e24cf8) ('driver_cursor' from 
> > cache) at SQLRelay.pm line 349
> >      -> $DBI::errstr (&) FETCH from lasth=HASH
> >      >> DBD::SQLRelay::st::errstr
> >      <- $DBI::errstr= undef
> > 
> > Looks to me like there is no "driver_cursor" to handle the job.
> > 
> > I've set in sqlrelay.conf:
> > 
> > connections="10"
> > maxconnections="32"
> > cursors="32"
> > 
> > Am I barking up the wrong tree here?
> > 
> 
> 

Re: [Sqlrelay-discussion] (no subject)

[David M. <dav...@fi...>]

Oooh, that's not good.  Looks like the commit/rollback methods are
trying to get the error, but there is no way to get an error at the
connection level, only the cursor level.  The long term fix is to add
support for that.  In the short term, replace the commit and rollback
code in sqlrelay.php with this:

    // {{{ commit()

    /**
     * Commit the current transaction.
     */
    function commit()
    {
        if (sqlrcon_commit($this->connection) == 1) {
            return DB_OK;
        } else {
            # FIXME: need some way to get a rollback error
            return $this->raiseError(DB_ERROR, null, null, null,
                                                "commit failed");
        }
    }

    // }}}
    // {{{ rollback()

    /**
     * Roll back (undo) the current transaction.
     */
    function rollback()
    {
        if (sqlrcon_rollback($this->connection) == 1) {
            return DB_OK;
        } else {
            # FIXME: need some way to get a rollback error
            return $this->raiseError(DB_ERROR, null, null, null,
                                                "rollback failed");
        }
    }

    // }}}

Give it a shot and see how it goes.

Dave
dav...@fi...

On Mon, 2006-07-24 at 12:42 -0500, jo...@in... wrote:
> Hello all,
> We have sqlrelay version .37 installed on our server and we are getting the
> following error message:
> 
> Fatal error: Call to undefined function: sqlrcon_errormessage() in
> /usr/local/lib/php/DB/sqlrelay.php on line 601
> 
> This function doesn't seem to be defined in
> sqlrelay-0.37/src/api/php/sql_relay.C where all the other similar php sqlrcon
> functions are defined. Is this a bug with sqlrelay? If so, what would be the
> fix?
> 
> 
> thanks
> 
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Sqlrelay-discussion mailing list
> Sql...@li...
> https://lists.sourceforge.net/lists/listinfo/sqlrelay-discussion
> 

Re: [Sqlrelay-discussion] What are cursors and how many do I need?

[Stephen C. <st...@to...>]

For anyone who might search for this issue, it looks like "cursors" is a 
per connection specification and there is a limit of 38 per connection. 
  At least sqlrelay (0.37) terminates the connection if I try to specify 
more.

Stephen Carville wrote:
> I'm new to using sqlrelay to connect to an Oracle 10g database and this 
> is the first day in full production.  Every once in a while I get a 
> strange error that looks like I have a connection to an instance but I 
> canno toproicess any SQL.  From the log generated by DBI:
> 
>      -> prepare for DBD::SQLRelay::db (DBI::db=HASH(0x8e24758)~0x8e24a88 
> 'select
> 1 from dual') thr#8a610081
>      <- FETCH= ( SQLRelay::Connection=SCALAR(0x8e24c08) ) [1 items] 
> ('driver_connection' from cache) at SQLRelay.pm line 138
>      -> STORE for DBD::SQLRelay::st (DBI::st=HASH(0x8e24b78)~0x9179278 
> 'driver_database_handle' DBI::db=HASH(0x8e24a88)) thr#8a61008
>      <- STORE= 1 at SQLRelay.pm line 145
>      -> STORE for DBD::SQLRelay::st (DBI::st=HASH(0x8e24b78)~0x9179278 
> 'NUM_OF_PARAMS' 0) thr#8a61008
>      <- STORE= 1 at SQLRelay.pm line 146
>      -> STORE for DBD::SQLRelay::st (DBI::st=HASH(0x8e24b78)~0x9179278 
> 'driver_is_select' 1) thr#8a61008
>      <- STORE= 1 at SQLRelay.pm line 147
>      -> STORE for DBD::SQLRelay::st (DBI::st=HASH(0x8e24b78)~0x9179278 
> 'driver_cursor' SQLRelay::Cursor=SCALAR(0x8e24cf8)) thr#8a61008
>      <- STORE= 1 at SQLRelay.pm line 148
>      -> STORE for DBD::SQLRelay::st (DBI::st=HASH(0x8e24b78)~0x9179278 
> 'NUM_OF_PARAMS' 0) thr#8a61008
>      <- STORE= 1 at SQLRelay.pm line 158
>      <- prepare= DBI::st=HASH(0x8e24b78) at sql.pm line 185
>      -> execute for DBD::SQLRelay::st 
> (DBI::st=HASH(0x8e24b78)~0x9179278) thr#8a610081
> <- FETCH= SQLRelay::Cursor=SCALAR(0x8e24cf8) ('driver_cursor' from 
> cache) at SQLRelay.pm line 349
>      -> $DBI::errstr (&) FETCH from lasth=HASH
>      >> DBD::SQLRelay::st::errstr
>      <- $DBI::errstr= undef
> 
> Looks to me like there is no "driver_cursor" to handle the job.
> 
> I've set in sqlrelay.conf:
> 
> connections="10"
> maxconnections="32"
> cursors="32"
> 
> Am I barking up the wrong tree here?
> 


-- 
Stephen Carville <st...@to...>
Unix and Network Admin
Nationwide Totalflood
6033 W. Century Blvd
Los Angeles, CA 90045
310-342-3602

[Sqlrelay-discussion] Glibc error with Java API

[Rodrigo P. T. <te...@de...>]

Hi Folks,

I'm facing some errors using SQLRelay 0.36.4 with Java API as listed belo=
w.
I tried to update to the latest SQLRelay version (0.37) but nothing chang=
es the error still happening.
When that error happens the Java App is killed!

2006-07-24 15:31:57.535476500 *** glibc detected *** free(): invalid
next size (fast): 0x08069680 ***

2006-07-24 15:20:53.190113500 *** glibc detected *** free(): invalid
next size (fast): 0x0806e300 ***

2006-07-24 15:19:07.109816500 *** glibc detected *** free(): invalid
next size (fast): 0x080b5f18 ***

2006-07-24 14:55:28.414175500 *** glibc detected *** free(): invalid
next size (fast): 0x08105270 ***

2006-07-24 14:53:42.518603500 *** glibc detected *** free(): invalid
next size (fast): 0x08106058 ***

2006-07-24 14:53:12.011833500 *** glibc detected *** free(): invalid
pointer: 0x08133558 ***

2006-07-24 14:51:10.687502500 *** glibc detected *** malloc(): memory
corruption: 0x08128c28 ***

2006-07-24 14:50:25.076671500 *** glibc detected *** free(): invalid
next size (fast): 0x080f5738 ***

2006-07-24 14:48:39.040298500 *** glibc detected *** free(): invalid
pointer: 0x08133468 ***

2006-07-24 14:47:53.374118500 *** glibc detected *** free(): invalid
next size (fast): 0x08139610 ***

2006-07-24 14:47:07.763850500 *** glibc detected *** free(): invalid
pointer: 0x08167e98 ***

2006-07-24 14:44:21.419332500 *** glibc detected *** free(): invalid
next size (fast): 0x08128440 ***

2006-07-24 14:43:20.713662500 *** glibc detected *** corrupted
double-linked list: 0x08139608 ***

2006-07-24 14:37:17.769239500 *** glibc detected *** free(): invalid
next size (fast): 0x0806bef0 ***

2006-07-24 14:29:14.538502500 *** glibc detected *** free(): invalid
next size (fast): 0x080f8918 ***


Its happening on some (random) SGBD operations (select, update, delete, e=
tc).

Informations about O.S.:
Mandriva 2006 Kernel 2.6.12-12mdk
glibc-2.3.5-5mdk
gcc-4.0.1-5mdk
gcc-c++-4.0.1-5mdk

Looks like there is some memory leak on SQLRelay.
Thanks for any help!

Telles

[Sqlrelay-discussion] (no subject)

[<jo...@in...>]

Hello all,
We have sqlrelay version .37 installed on our server and we are getting the
following error message:

Fatal error: Call to undefined function: sqlrcon_errormessage() in
/usr/local/lib/php/DB/sqlrelay.php on line 601

This function doesn't seem to be defined in
sqlrelay-0.37/src/api/php/sql_relay.C where all the other similar php sqlrcon
functions are defined. Is this a bug with sqlrelay? If so, what would be the
fix?


thanks

Re: [Sqlrelay-discussion] can not 'use $db' ??

[Devananda <kar...@ya...>]

David Muse wrote:
> I recently (since the last prerelease) updated the mysql code to only
> use mysql_stmt_prepare for certain queries and use the older style code
> for others.  So far, it only uses the older style code for create/drop
> procedures statements, but I'll update the list.
> 
> Dave

I pulled the latest source from CVS and this hasn't been added yet, so 
here is a patch that corrects it.

Index: src/connections/mysql/mysqlconnection.C
===================================================================
RCS file: 
/cvsroot/sqlrelay/sqlrelay/src/connections/mysql/mysqlconnection.C,v
retrieving revision 1.48
diff -r1.48 mysqlconnection.C
150c150
<       return false;
---
 >       return true;
205,206c205,206
<       storedproc.compile("^\\s*(create|CREATE|drop|DROP)\\s+"
<                       "(procedure|PROCEDURE|function|FUNCTION)\\s+");
---
 >       storedproc.compile(
 > 
"^\\s*(delete|DELETE|do|DO|insert|INSERT|replace|REPLACE|select|SELECT|set|SET|update|UPDATE)\\s+");
239c239
<       if (storedproc.match(query)) {
---
 >       if (!storedproc.match(query)) {


Regards,
Devananda


> 
> On Wed, 2006-06-21 at 13:17 -0700, Devananda wrote:
>> The problem seems to be line 260 in
>> connections/mysql/mysqlconnection.C:
>>
>> return !mysql_stmt_prepare(stmt,query,length);
>>
>> and the assumption that all queries can be run as prepared statements.
>> I looked briefly in the other connectors, and I see the same treatment
>> of queries (prepare them all). However, according to the MySQL
>> documentation, this can't be done for 5.0 :(
>>
>> See
>> http://dev.mysql.com/doc/refman/5.0/en/c-api-prepared-statements.html :
>>         The following statements can be used as prepared statements:
>>         CREATE TABLE, DELETE, DO, INSERT, REPLACE, SELECT, SET,
>>         UPDATE, and most SHOW statements. Other statements are not
>>         supported in MySQL 5.0.
>>
>> Regards,
>> Devananda
>>
>>
>>
>> Devananda wrote: 
>>> This is particularly odd, I think....
>>>
>>> I've compiled the latest 0.38pre2 (along with the new rudiments), and my 
>>> test scripts failed immediately with a strange error... I ran sqlrsh to 
>>> verify, and sure enough, sqlrsh returns an error when I simply "use $db"
>>>
>>>   
>>>> 0> show tables from test;
>>>> Tables_in_test
>>>> ==============
>>>> bin_test      
>>>> fs            
>>>>         Rows Returned   : 2
>>>>         Fields Returned : 2
>>>>         System time     : 30000
>>>>
>>>> 0> use test;
>>>> This command is not supported in the prepared statement protocol yet
>>>>
>>>>         Rows Returned   : 0
>>>>         Fields Returned : 0
>>>>         System time     : 30000
>>>>     
>>>
>>> The same error message is returned for other commands, such as 'show 
>>> slave status' and 'show create table'.
>>>
>>> This is all on a Fedora 3 server, talking to MySQL 5.0.18.
>>>
>>> Please let me know if there is anything I can do to help fix this, I 
>>> would like to be able to put 0.38 into use on my development server (we 
>>> need the inputBindBlob support that is lacking in 0.37).
>>>
>>> Regards,
>>> Devananda
>>>
>>>

[Sqlrelay-discussion] infinite loop

[Devananda <kar...@ya...>]

Dear List,

sqlrelay is regularly getting stuck in an infinite reconnect loop on 
both servers on which I am running it right now. This seems to happen 
/most often/ after hours of inactivity, but not always. I've spent a 
week tracking this down, and have found where the MySQL C API is 
returning an unexpected result, and sqlrelay goes into an infinite loop 
because of it.

First, the platform; sqlrelay pulled from CVS a few weeks ago, Fedora 
4/5, and MySQL 5.0.18-5.0.22.

The loop itself happens inside the sqlrconnection_svr::handleQuery 
function, where the inline comments clearly state "loop here to handle 
down databases" :) The problem is that the MySQL C API (erroneously?) 
returns an error message (CR_SERVER_GONE_ERROR) at mysqlconnection.C:542

if ((queryresult=mysql_stmt_execute(stmt))) {

As a result, sqlrconnection_svr::processQuery returns FALSE, which 
triggers sqlrconnection_svr::handleError, which can not returnError() 
because the database appears to be down, and therefor calls reLogIn(). 
However, the database is not actually down, and sqlrelay reconnects to 
it easily, tries to rerun the initial query, and gets the same return 
value of CR_SERVER_GONE_ERROR, thus beginning the loop again.

Running sqlr-status during this time shows number of connections 
skyrocketing, and asking MySQL to "SHOW STATUS" shows the number of 
client connections (Aborted_clients and Connections) to be increasing as 
well. "SHOW PROCESSLIST" also displays sqlrelay's connections, which are 
being established and closed as fast as the server is able.

This looks as though it could be caused by the bug reported at 
http://bugs.mysql.com/bug.php?id=19927.

I have added some code to detect and break out of the infinite loop, 
hoping that would patch sqlrelay while MySQL fixes their bugs, however, 
simply breaking out of the loop does not sufficiently fix what ever is 
wrong. Any further debugging is beyond my abilities :(

If anyone can help, it would be very appreciated. We are on a pretty 
tight development schedule, and this is really slowing us down. If 
anyone needs to see a sqlrelay debug file, let me know and I'll send it 
off-list.



Best Regards,
Devananda van der Veen

[Sqlrelay-discussion] What are cursors and how many do I need?

[Stephen C. <st...@to...>]

I'm new to using sqlrelay to connect to an Oracle 10g database and this 
is the first day in full production.  Every once in a while I get a 
strange error that looks like I have a connection to an instance but I 
canno toproicess any SQL.  From the log generated by DBI:

     -> prepare for DBD::SQLRelay::db (DBI::db=HASH(0x8e24758)~0x8e24a88 
'select
1 from dual') thr#8a610081
     <- FETCH= ( SQLRelay::Connection=SCALAR(0x8e24c08) ) [1 items] 
('driver_connection' from cache) at SQLRelay.pm line 138
     -> STORE for DBD::SQLRelay::st (DBI::st=HASH(0x8e24b78)~0x9179278 
'driver_database_handle' DBI::db=HASH(0x8e24a88)) thr#8a61008
     <- STORE= 1 at SQLRelay.pm line 145
     -> STORE for DBD::SQLRelay::st (DBI::st=HASH(0x8e24b78)~0x9179278 
'NUM_OF_PARAMS' 0) thr#8a61008
     <- STORE= 1 at SQLRelay.pm line 146
     -> STORE for DBD::SQLRelay::st (DBI::st=HASH(0x8e24b78)~0x9179278 
'driver_is_select' 1) thr#8a61008
     <- STORE= 1 at SQLRelay.pm line 147
     -> STORE for DBD::SQLRelay::st (DBI::st=HASH(0x8e24b78)~0x9179278 
'driver_cursor' SQLRelay::Cursor=SCALAR(0x8e24cf8)) thr#8a61008
     <- STORE= 1 at SQLRelay.pm line 148
     -> STORE for DBD::SQLRelay::st (DBI::st=HASH(0x8e24b78)~0x9179278 
'NUM_OF_PARAMS' 0) thr#8a61008
     <- STORE= 1 at SQLRelay.pm line 158
     <- prepare= DBI::st=HASH(0x8e24b78) at sql.pm line 185
     -> execute for DBD::SQLRelay::st 
(DBI::st=HASH(0x8e24b78)~0x9179278) thr#8a610081
<- FETCH= SQLRelay::Cursor=SCALAR(0x8e24cf8) ('driver_cursor' from 
cache) at SQLRelay.pm line 349
     -> $DBI::errstr (&) FETCH from lasth=HASH
     >> DBD::SQLRelay::st::errstr
     <- $DBI::errstr= undef

Looks to me like there is no "driver_cursor" to handle the job.

I've set in sqlrelay.conf:

connections="10"
maxconnections="32"
cursors="32"

Am I barking up the wrong tree here?

-- 
Stephen Carville <st...@to...>
Unix and Network Admin
Nationwide Totalflood
6033 W. Century Blvd
Los Angeles, CA 90045
310-342-3602

[Sqlrelay-discussion] SIGSEGV when trying to create temporary table

[Devananda <kar...@ya...>]

When sending CREATE TEMPORARY TABLE... either from PHP, or through 
sqlrhsh, the sqlr-connection segfaults. I ran the connection process in 
gdb, and received the following info:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 2596304 (LWP 4296)]
0x0093fa39 in sqlrcursor_svr::checkForTempTable ()
   from /usr/local/firstworks/lib/libsqlrconnection_debug-0.37.so.1

The version of sql relay in which this happened is a slightly old 0.37, 
connecting to both MySQL 4.1.18 and 5.0.22 (the segfault happens with 
both connections). I will attempt to verify that this affects the latest 
sqlrelay (pulled from CVS) as soon as I can hammer out a library issue 
(probably early next week).


Regards,
Devananda vdv

Re: [Sqlrelay-discussion] SQLRelay and PHP PEAR DB package

[fo o <fo...@ya...>]

It is in sqlrelay source package.
  src/api/phppeardb/sqlrelay.php
  

Aleksandr Krichanov <san...@uk...> wrote:
  

fo o wrote:

Thank you, but problem - that i haven't this file-> "sqlrelay.php"
and in php class PEAR DB i can't find it.
http://pear.php.net/package/DB

can you give me a direct link on this file, or send it on my email?

Thank you very mutch !

> Try place sqlrelay.php into /usr/local/lib/php/DB/
> 




 		
---------------------------------
Do you Yahoo!?
 Next-gen email? Have it all with the  all-new Yahoo! Mail Beta.

Re: [Sqlrelay-discussion] SQLRelay and PHP PEAR DB package

[Aleksandr K. <san...@uk...>]

fo o <fo...@ya...> wrote:

 Thank you, but problem - that i haven't this file-> "sqlrelay.php"
and in php class PEAR DB i can't find it.
http://pear.php.net/package/DB

can you give me a direct link on this file, or send it on my email?

Thank you very mutch !

> Try place sqlrelay.php into /usr/local/lib/php/DB/
>    
   
    

Re: [Sqlrelay-discussion] SQLRelay and PHP PEAR DB package

[fo o <fo...@ya...>]

Try place sqlrelay.php into /usr/local/lib/php/DB/
   
  

Àëåêñàíä?Êðè÷àíîâ <san...@uk...> wrote:
  Hello

first of all, sorry for my english, it's not my native language.

I have such problem
At page http://sqlrelay.sourceforge.net/sqlrelay/programming/phppeardb.html
i found that SqlRelay can work with PHP PEAT DB class

But when i try the example

require_once 'DB.php';

$db = DB::connect("sqlrelay://testuser:testpassword@testhost:9000/testdb");
if (DB::isError($db)) {
die ($db->getMessage());
}

i got next error:
Notice: Only variable references should be returned by reference in /home/test/www/PEAR.php
on line 425
DB Error: not found

It seems to me that in folder DB i must have file sqlrelay.php, but i
can't find such file

i also couldn't find it in the google

If you can help me, it would be perfect :)

Thank you

With Best Regards.

Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Sqlrelay-discussion mailing list
Sql...@li...
https://lists.sourceforge.net/lists/listinfo/sqlrelay-discussion


 		
---------------------------------
Yahoo! Music Unlimited - Access over 1 million songs.Try it free. 

[Sqlrelay-discussion] SQLRelay and PHP PEAR DB package

[<san...@uk...>]

    Hello

first of all, sorry for my english, it's not my native language.

I have such problem
At page http://sqlrelay.sourceforge.net/sqlrelay/programming/phppeardb.html
i found that SqlRelay can work with PHP PEAT DB class

But when i try the example

require_once 'DB.php';

$db = DB::connect("sqlrelay://testuser:testpassword@testhost:9000/testdb");
if (DB::isError($db)) {
        die ($db->getMessage());
}

i got next error:
Notice: Only variable references should be returned by reference in /home/test/www/PEAR.php
on line 425
DB Error: not found

It seems to me that in folder DB i must have file sqlrelay.php,  but i
can't find such file

i also couldn't find it in the google

If you can help me, it would be perfect :)

Thank you

With Best Regards.

Re: [Sqlrelay-discussion] SQLRelay and large numbers in Oracle (other databases too?)

[David M. <dav...@fi...>]

Those sound like good possible solutions.  I'll look into it a bit and
see what I can come up with.  Hopefully I'll get something in place for
0.38.

Dave
dav...@fi...

On Thu, 2006-06-22 at 13:43 +0200, Maciej Wiśniowski wrote:
> Hi
> 
> We've found serious problem with SQLRelay.
> It doesn't support large numbers (at last with 
> Oracle and python).
> 
> 
> Try this structure in OracleDB (I've used
> free Oracle Express edition):
> 
> -------------------------------
> CREATE TABLE  "TNUMBERS" 
>    (	"ID" NUMBER, 
> 	"NUMBER1" NUMBER(20,2), 
> 	"NUMBER2" NUMBER(20,2), 
> 	 CONSTRAINT "TNUMBERS_PK" PRIMARY KEY ("ID") ENABLE
>    )
> /
> 
> 
> insert into tnumbers (id, number1, number2) 
>      values (1, 143393735125.58, 9999999999999.04)
> insert into tnumbers (id, number1, number2) 
>      values (2, 143393735125.58, 9999999999999.05)
> insert into tnumbers (id, number1, number2) 
>      values (3, 999999999999999999.04, 999999999999999999.05)
> insert into tnumbers (id, number1, number2) 
>      values (4, 999999999999999.04, 999999999999999.05)
> 
> -------------------------------
> 
> 
> In Python I get the result as ('%f' used):
> 
> 1.0	143393735125.579987	    9999999999999.039062
> 2.0	143393735125.579987	    9999999999999.050781
> 3.0	1000000000000000000.000000  1000000000000000000.000000
> 4.0     999999999999999.000000      999999999999999.000000
> 
> So it is incorrect.
> 
> There are two problems we've found. 
> First is the problem with range of C datatypes used 
> by SQLRelay for numbers and second is the problem 
> with float data type in Python which fails with more 
> than 13 digits:
> 
> >>> a = 99999999999999.04
> >>> b = 99999999999999.05
> >>> a
> 99999999999999.047
> >>> b
> 99999999999999.047
> 
> I'm not sure what can/should be done with this. 
> AFAIR largest numeric type in C is long double 
> and (depending on compiler) it is 15 digits long. 
> We need to have 20.2 numbers...
> 
> I think the good solution is implemented in psycopg2.
> PostgreSQL 'money' types are returned as python's 
> Decimal data type (availaible in python2.4 and with 
> addition of decimal.py file in python2.3 too) which 
> can support such a large numbers, but is different 
> than float, eg.:
> 
> >>> import decimal
> >>> a = decimal.Decimal('12.23')
> >>> a + 1.0
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
> TypeError: unsupported operand type(s) for +: 'Decimal' and 'float'
> 
> 
> In DCOracle2 we've changed it's source to make it always 
> return Decimal (never float from database). I think 
> the better is to be able to customize returned data 
> type somewhere in connection parameters. Any 
> other ideas/solutions?
> 
>