sqlrelay-discussion Mailing List for SQL Relay (Page 3)
Brought to you by:
mused
Menu
▾
▴
sqlrelay-discussion — Discussion of topics related to SQL Relay
You can subscribe to this list here.
| 2005 |
Jan
|
Feb
(20) |
Mar
(27) |
Apr
(17) |
May
(32) |
Jun
(45) |
Jul
(49) |
Aug
(68) |
Sep
(44) |
Oct
(29) |
Nov
(64) |
Dec
(25) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2006 |
Jan
(61) |
Feb
(22) |
Mar
(25) |
Apr
(31) |
May
(18) |
Jun
(28) |
Jul
(19) |
Aug
(16) |
Sep
(8) |
Oct
(17) |
Nov
(32) |
Dec
(4) |
| 2007 |
Jan
(20) |
Feb
(25) |
Mar
(5) |
Apr
(12) |
May
(11) |
Jun
(18) |
Jul
(16) |
Aug
(22) |
Sep
(37) |
Oct
(20) |
Nov
(11) |
Dec
(2) |
| 2008 |
Jan
(11) |
Feb
(33) |
Mar
(12) |
Apr
(18) |
May
(22) |
Jun
(31) |
Jul
(23) |
Aug
(6) |
Sep
|
Oct
(10) |
Nov
(22) |
Dec
|
| 2009 |
Jan
(12) |
Feb
(8) |
Mar
(11) |
Apr
(20) |
May
(18) |
Jun
(7) |
Jul
(27) |
Aug
(2) |
Sep
(10) |
Oct
(5) |
Nov
(2) |
Dec
(1) |
| 2010 |
Jan
(11) |
Feb
(18) |
Mar
(10) |
Apr
(28) |
May
(28) |
Jun
|
Jul
(27) |
Aug
(9) |
Sep
(21) |
Oct
(2) |
Nov
(2) |
Dec
(11) |
| 2011 |
Jan
|
Feb
(2) |
Mar
(4) |
Apr
(2) |
May
(2) |
Jun
(44) |
Jul
(9) |
Aug
(2) |
Sep
(12) |
Oct
(7) |
Nov
(11) |
Dec
(7) |
| 2012 |
Jan
(5) |
Feb
|
Mar
(9) |
Apr
(9) |
May
(12) |
Jun
|
Jul
(13) |
Aug
(3) |
Sep
(3) |
Oct
(1) |
Nov
(1) |
Dec
(10) |
| 2013 |
Jan
(21) |
Feb
(3) |
Mar
(4) |
Apr
|
May
(3) |
Jun
(2) |
Jul
(3) |
Aug
(3) |
Sep
(3) |
Oct
|
Nov
|
Dec
(4) |
| 2014 |
Jan
(7) |
Feb
|
Mar
(1) |
Apr
|
May
(2) |
Jun
|
Jul
(4) |
Aug
(2) |
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2016 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2017 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2021 |
Jan
|
Feb
|
Mar
|
Apr
(3) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2022 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: David M. <dav...@fi...> - 2013-01-18 20:12:19
|
Interesting. The mysql client for 5.5 doesn't appear to be against the libmysqlclient library at all: [dmuse@localhost mysql]$ mysql --version mysql Ver 14.14 Distrib 5.5.28, for Linux (x86_64) using readline 5.1 [dmuse@localhost mysql]$ ldd /usr/bin/mysql linux-vdso.so.1 => (0x00007fff22d33000) libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003775200000) libz.so.1 => /lib64/libz.so.1 (0x0000003775e00000) librt.so.1 => /lib64/librt.so.1 (0x0000003775a00000) libssl.so.10 => /lib64/libssl.so.10 (0x0000003785e00000) libcrypto.so.10 => /lib64/libcrypto.so.10 (0x0000003783a00000) libdl.so.2 => /lib64/libdl.so.2 (0x0000003775600000) libncurses.so.5 => /lib64/libncurses.so.5 (0x0000003788600000) libtinfo.so.5 => /lib64/libtinfo.so.5 (0x0000003785a00000) libstdc++.so.6 => /lib64/libstdc++.so.6 (0x000000377e600000) libm.so.6 => /lib64/libm.so.6 (0x0000003776200000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x0000003778600000) libc.so.6 => /lib64/libc.so.6 (0x0000003774e00000) /lib64/ld-linux-x86-64.so.2 (0x0000003774a00000) libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x0000003782e00000) libkrb5.so.3 => /lib64/libkrb5.so.3 (0x0000003783200000) libcom_err.so.2 => /lib64/libcom_err.so.2 (0x000000377fe00000) libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x0000003783e00000) libkrb5support.so.0 => /lib64/libkrb5support.so.0 (0x0000003783600000) libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x0000003784600000) libresolv.so.2 => /lib64/libresolv.so.2 (0x0000003776a00000) libselinux.so.1 => /lib64/libselinux.so.1 (0x0000003776600000) or use any of the mysql client api functions: [dmuse@localhost mysql]$ ltrace -e "mysql_real_connect" mysql --host=db --user=test --password=test ERROR 1045 (28000): Access denied for user 'test'@'192.168.1.73' (using password: YES) 5.1 uses libmysqlclient though: [dmuse@fedora ~]$ mysql --version mysql Ver 14.14 Distrib 5.1.60, for redhat-linux-gnu (i386) using readline 5.1 [dmuse@fedora ~]$ ldd /usr/bin/mysql linux-gate.so.1 => (0x0043e000) libncursesw.so.5 => /lib/libncursesw.so.5 (0x00475000) libtinfo.so.5 => /lib/libtinfo.so.5 (0x0033f000) libpthread.so.0 => /lib/libpthread.so.0 (0x0079f000) libmysqlclient.so.16 => /usr/lib/mysql/libmysqlclient.so.16 (0x00110000) libcrypt.so.1 => /lib/libcrypt.so.1 (0x00511000) libnsl.so.1 => /lib/libnsl.so.1 (0x006ba000) libssl.so.10 => /usr/lib/libssl.so.10 (0x00284000) libcrypto.so.10 => /lib/libcrypto.so.10 (0x007ba000) libz.so.1 => /lib/libz.so.1 (0x00e5c000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00d0e000) libm.so.6 => /lib/libm.so.6 (0x00c26000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00b1a000) libc.so.6 => /lib/libc.so.6 (0x00946000) libdl.so.2 => /lib/libdl.so.2 (0x002dc000) /lib/ld-linux.so.2 (0x00c60000) libfreebl3.so => /lib/libfreebl3.so (0x002e1000) libgssapi_krb5.so.2 => /lib/libgssapi_krb5.so.2 (0x0035f000) libkrb5.so.3 => /lib/libkrb5.so.3 (0x00541000) libcom_err.so.2 => /lib/libcom_err.so.2 (0x0032e000) libk5crypto.so.3 => /lib/libk5crypto.so.3 (0x00397000) libresolv.so.2 => /lib/libresolv.so.2 (0x00ebc000) libkrb5support.so.0 => /lib/libkrb5support.so.0 (0x0072e000) libkeyutils.so.1 => /lib/libkeyutils.so.1 (0x0041e000) libselinux.so.1 => /lib/libselinux.so.1 (0x00e97000) I'm not sure what they did in 5.5. Maybe they static-linked and inlined the functions or something. Strange. That explains why it's not working though. I would expect it to work with any program that uses libmysqlclient. Try it with a third-party mysql app and see what happens. Dave On 01/18/2013 12:46 PM, David Muse wrote: > Hmmm. The mysql 5.1 library should work with 5.5. I have a client that > I think it using it with 5.5, but I could be wrong about that. It's > possible that one of the MySQL internal structures changed between 5.1 > and 5.5 and the code needs to be updated to handle that. Take a look at > the file src/api/mysql/mysql.cpp. Near the top there are several > ifdef's for different versions of MySQL. Compare the structures defined > for 5.1 with the ones defined in the mysql headers for 5.5. If the > sizes look different, then that could be the problem. Otherwise, you'd > have to enable debug and trace through it. > > I just looked at the code for the postgres drop-in library and I don't > see a function that returns the protocol version, so that could be > tricky to solve. It might be returned in a struct or there could be > some set of commands that get run or something. I'll look into it. It > should be possible to get it working in an upcoming release. > > Dave > > On 01/18/2013 12:23 PM, Petros Moisiadis wrote: >> I' ve tested sqlrelay's drop-in replacement libraries for MySQL and >> PostgreSQL on Debian Wheezy (x86_64). >> >> The drop-in for MySQL does not seem to work. It just hangs when trying >> to connect with the mysql client program. It asks for password and after >> entering it, it freezes without ever giving back a mysql prompt. Maybe >> this is related to the fact that Debian Wheezy comes with mysql 5.5, but >> sqlrelay provides libraries up to 5.1? If this is not relevant, I would >> be glad to do any tests needed to narrow down the possible causes of the >> problem. >> >> The drop-in replacement library for PostgreSQL works when using the psql >> client program. >> However, it is not usable if trying to connect with psycopg2, the most >> popular library to interface with postgres from python. In particular, >> psycopg2 checks for the protocol version of the connection and if it is >> not 3, it exits. Maybe sqlrelay's implementation of postgres api does >> not support protocol version requests. Dave, if that is the case, would >> it be easy to include support for this type of requests in a following >> release of sqlrelay? >> >> ------------------------------------------------------------------------------ >> >> Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and >> much more. Get web development skills now with LearnDevNow - >> 350+ hours of step-by-step video tutorials by Microsoft MVPs and experts. >> SALE $99.99 this month only -- learn more at: >> http://p.sf.net/sfu/learnmore_122812 >> _______________________________________________ >> Sqlrelay-discussion mailing list >> Sql...@li... >> https://lists.sourceforge.net/lists/listinfo/sqlrelay-discussion >> >> >> _______________________________________________________ >> Unlimited Disk, Data Transfer, PHP/MySQL Domain Hosting >> http://www.doteasy.com >> |
|
From: David M. <dav...@fi...> - 2013-01-18 17:47:07
|
Hmmm. The mysql 5.1 library should work with 5.5. I have a client that I think it using it with 5.5, but I could be wrong about that. It's possible that one of the MySQL internal structures changed between 5.1 and 5.5 and the code needs to be updated to handle that. Take a look at the file src/api/mysql/mysql.cpp. Near the top there are several ifdef's for different versions of MySQL. Compare the structures defined for 5.1 with the ones defined in the mysql headers for 5.5. If the sizes look different, then that could be the problem. Otherwise, you'd have to enable debug and trace through it. I just looked at the code for the postgres drop-in library and I don't see a function that returns the protocol version, so that could be tricky to solve. It might be returned in a struct or there could be some set of commands that get run or something. I'll look into it. It should be possible to get it working in an upcoming release. Dave On 01/18/2013 12:23 PM, Petros Moisiadis wrote: > I' ve tested sqlrelay's drop-in replacement libraries for MySQL and > PostgreSQL on Debian Wheezy (x86_64). > > The drop-in for MySQL does not seem to work. It just hangs when trying > to connect with the mysql client program. It asks for password and after > entering it, it freezes without ever giving back a mysql prompt. Maybe > this is related to the fact that Debian Wheezy comes with mysql 5.5, but > sqlrelay provides libraries up to 5.1? If this is not relevant, I would > be glad to do any tests needed to narrow down the possible causes of the > problem. > > The drop-in replacement library for PostgreSQL works when using the psql > client program. > However, it is not usable if trying to connect with psycopg2, the most > popular library to interface with postgres from python. In particular, > psycopg2 checks for the protocol version of the connection and if it is > not 3, it exits. Maybe sqlrelay's implementation of postgres api does > not support protocol version requests. Dave, if that is the case, would > it be easy to include support for this type of requests in a following > release of sqlrelay? > > ------------------------------------------------------------------------------ > Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and > much more. Get web development skills now with LearnDevNow - > 350+ hours of step-by-step video tutorials by Microsoft MVPs and experts. > SALE $99.99 this month only -- learn more at: > http://p.sf.net/sfu/learnmore_122812 > _______________________________________________ > Sqlrelay-discussion mailing list > Sql...@li... > https://lists.sourceforge.net/lists/listinfo/sqlrelay-discussion > > > _______________________________________________________ > Unlimited Disk, Data Transfer, PHP/MySQL Domain Hosting > http://www.doteasy.com > |
|
From: Petros M. <ern...@ya...> - 2013-01-18 17:23:12
|
I' ve tested sqlrelay's drop-in replacement libraries for MySQL and PostgreSQL on Debian Wheezy (x86_64). The drop-in for MySQL does not seem to work. It just hangs when trying to connect with the mysql client program. It asks for password and after entering it, it freezes without ever giving back a mysql prompt. Maybe this is related to the fact that Debian Wheezy comes with mysql 5.5, but sqlrelay provides libraries up to 5.1? If this is not relevant, I would be glad to do any tests needed to narrow down the possible causes of the problem. The drop-in replacement library for PostgreSQL works when using the psql client program. However, it is not usable if trying to connect with psycopg2, the most popular library to interface with postgres from python. In particular, psycopg2 checks for the protocol version of the connection and if it is not 3, it exits. Maybe sqlrelay's implementation of postgres api does not support protocol version requests. Dave, if that is the case, would it be easy to include support for this type of requests in a following release of sqlrelay? |
|
From: Petros M. <ern...@ya...> - 2013-01-18 16:48:43
|
In newer unixODBC releases the SQLROWSETSIZE type has been commented out as 'unsupported' for 64-bit and compilation of sqlrelay fails. In the hope that this does not have any side-effects, the attached patch file changes this to SQLULEN. |
|
From: Petros M. <ern...@ya...> - 2013-01-17 18:28:49
|
On 17/01/2013 01:32 ??, Petros Moisiadis wrote: > Good suggestion. I think that I found an explanation to the problem... > The debian packages put library files under > |"/usr/lib/x86_64-linux-gnu|" path, which is not checked by the > configure script. > > For example, here are lists of files in 'freetds-*' packages: > > |$ dpkg -L freetds-common|| > ||/.|| > ||/usr|| > ||/usr/share|| > ||/usr/share/doc|| > ||/usr/share/doc/freetds-common|| > ||/usr/share/doc/freetds-common/README|| > ||/usr/share/doc/freetds-common/NEWS.gz|| > ||/usr/share/doc/freetds-common/README.Debian|| > ||/usr/share/doc/freetds-common/changelog.Debian.gz|| > ||/usr/share/doc/freetds-common/copyright|| > ||/usr/share/doc/freetds-common/TODO.gz|| > ||/usr/share/doc/freetds-common/examples|| > ||/usr/share/doc/freetds-common/examples/locales.conf|| > ||/usr/share/doc/freetds-common/examples/freetds.conf.pl|| > ||/usr/share/doc/freetds-common/TODO.Debian|| > ||/usr/share/doc/freetds-common/changelog.gz|| > ||/usr/share/freetds|| > ||/usr/share/freetds/freetds.conf|| > ||/usr/share/man|| > ||/usr/share/man/man5|| > ||/usr/share/man/man5/freetds.conf.5.gz|| > ||/usr/lib|| > ||/usr/lib/odbc|| > ||/usr/include|| > ||/etc|| > ||/etc/freetds|| > ||/usr/share/doc/freetds-common/examples/freetds.conf|| > || > ||$ dpkg -L freetds-dev|| > ||/.|| > ||/usr|| > ||/usr/share|| > ||/usr/share/doc|| > ||/usr/share/doc/freetds-dev|| > ||/usr/share/doc/freetds-dev/changelog.Debian.gz|| > ||/usr/share/doc/freetds-dev/copyright|| > ||/usr/share/doc/freetds-dev/changelog.gz|| > ||/usr/lib|| > ||/usr/lib/x86_64-linux-gnu|| > ||/usr/lib/x86_64-linux-gnu/libct.a|| > ||/usr/lib/x86_64-linux-gnu/libsybdb.a|| > ||/usr/include|| > ||/usr/include/cspublic.h|| > ||/usr/include/ctpublic.h|| > ||/usr/include/sybdb.h|| > ||/usr/include/sqldb.h|| > ||/usr/include/odbcss.h|| > ||/usr/include/syberror.h|| > ||/usr/include/cstypes.h|| > ||/usr/include/tds_sysdep_public.h|| > ||/usr/include/bkpublic.h|| > ||/usr/include/sqlfront.h|| > ||/usr/include/sybfront.h|| > ||/usr/lib/x86_64-linux-gnu/libsybdb.so|| > ||/usr/lib/x86_64-linux-gnu/libct.so > > ||$ dpkg -L freetds-bin|| > ||/.|| > ||/usr|| > ||/usr/bin|| > ||/usr/bin/freebcp|| > ||/usr/bin/defncopy|| > ||/usr/bin/osql|| > ||/usr/bin/tsql|| > ||/usr/bin/bsqldb|| > ||/usr/bin/datacopy|| > ||/usr/bin/fisql|| > ||/usr/bin/tdspool|| > ||/usr/bin/bsqlodbc|| > ||/usr/share|| > ||/usr/share/doc|| > ||/usr/share/doc/freetds-bin|| > ||/usr/share/doc/freetds-bin/changelog.Debian.gz|| > ||/usr/share/doc/freetds-bin/copyright|| > ||/usr/share/doc/freetds-bin/changelog.gz|| > ||/usr/share/man|| > ||/usr/share/man/man1|| > ||/usr/share/man/man1/defncopy.1.gz|| > ||/usr/share/man/man1/tsql.1.gz|| > ||/usr/share/man/man1/osql.1.gz|| > ||/usr/share/man/man1/datacopy.1.gz|| > ||/usr/share/man/man1/bsqldb.1.gz|| > ||/usr/share/man/man1/freebcp.1.gz|| > ||/usr/share/man/man1/fisql.1.gz|| > ||/usr/share/man/man1/bsqlodbc.1.gz|| > | > > So, I guess that a solution would have to do with somehow making > sqlrelay's autoconf configuration/bootstrap files aware of the > '/usr/lib/x86_64-linux-gnu' path.|| > > Thanks. Finally, I patched acsite.m4 to also search in the /usr/lib/[i386|x86_64]-linux-gnu paths used in multiarch debian systems, ran again the autogen.sh script and now configure script finds all the libs. I'm attaching the patch file. Thanks for helping me find out what was going wrong. |
|
From: Petros M. <ern...@ya...> - 2013-01-17 11:32:44
|
On 16/01/2013 09:36 μμ, David Muse wrote: > Weird. I don't see anything unusual in the configure output or > config.log except for the lack of ANSI C header files, and in that case, > the configure script failed to write out a test program for some reason. > > Could you post the list of files in the freetds and freetds-dev > packages? Maybe that will shed some light on the issue. > > Dave Good suggestion. I think that I found an explanation to the problem... The debian packages put library files under |"/usr/lib/x86_64-linux-gnu|" path, which is not checked by the configure script. For example, here are lists of files in 'freetds-*' packages: |$ dpkg -L freetds-common|| ||/.|| ||/usr|| ||/usr/share|| ||/usr/share/doc|| ||/usr/share/doc/freetds-common|| ||/usr/share/doc/freetds-common/README|| ||/usr/share/doc/freetds-common/NEWS.gz|| ||/usr/share/doc/freetds-common/README.Debian|| ||/usr/share/doc/freetds-common/changelog.Debian.gz|| ||/usr/share/doc/freetds-common/copyright|| ||/usr/share/doc/freetds-common/TODO.gz|| ||/usr/share/doc/freetds-common/examples|| ||/usr/share/doc/freetds-common/examples/locales.conf|| ||/usr/share/doc/freetds-common/examples/freetds.conf.pl|| ||/usr/share/doc/freetds-common/TODO.Debian|| ||/usr/share/doc/freetds-common/changelog.gz|| ||/usr/share/freetds|| ||/usr/share/freetds/freetds.conf|| ||/usr/share/man|| ||/usr/share/man/man5|| ||/usr/share/man/man5/freetds.conf.5.gz|| ||/usr/lib|| ||/usr/lib/odbc|| ||/usr/include|| ||/etc|| ||/etc/freetds|| ||/usr/share/doc/freetds-common/examples/freetds.conf|| || ||$ dpkg -L freetds-dev|| ||/.|| ||/usr|| ||/usr/share|| ||/usr/share/doc|| ||/usr/share/doc/freetds-dev|| ||/usr/share/doc/freetds-dev/changelog.Debian.gz|| ||/usr/share/doc/freetds-dev/copyright|| ||/usr/share/doc/freetds-dev/changelog.gz|| ||/usr/lib|| ||/usr/lib/x86_64-linux-gnu|| ||/usr/lib/x86_64-linux-gnu/libct.a|| ||/usr/lib/x86_64-linux-gnu/libsybdb.a|| ||/usr/include|| ||/usr/include/cspublic.h|| ||/usr/include/ctpublic.h|| ||/usr/include/sybdb.h|| ||/usr/include/sqldb.h|| ||/usr/include/odbcss.h|| ||/usr/include/syberror.h|| ||/usr/include/cstypes.h|| ||/usr/include/tds_sysdep_public.h|| ||/usr/include/bkpublic.h|| ||/usr/include/sqlfront.h|| ||/usr/include/sybfront.h|| ||/usr/lib/x86_64-linux-gnu/libsybdb.so|| ||/usr/lib/x86_64-linux-gnu/libct.so ||$ dpkg -L freetds-bin|| ||/.|| ||/usr|| ||/usr/bin|| ||/usr/bin/freebcp|| ||/usr/bin/defncopy|| ||/usr/bin/osql|| ||/usr/bin/tsql|| ||/usr/bin/bsqldb|| ||/usr/bin/datacopy|| ||/usr/bin/fisql|| ||/usr/bin/tdspool|| ||/usr/bin/bsqlodbc|| ||/usr/share|| ||/usr/share/doc|| ||/usr/share/doc/freetds-bin|| ||/usr/share/doc/freetds-bin/changelog.Debian.gz|| ||/usr/share/doc/freetds-bin/copyright|| ||/usr/share/doc/freetds-bin/changelog.gz|| ||/usr/share/man|| ||/usr/share/man/man1|| ||/usr/share/man/man1/defncopy.1.gz|| ||/usr/share/man/man1/tsql.1.gz|| ||/usr/share/man/man1/osql.1.gz|| ||/usr/share/man/man1/datacopy.1.gz|| ||/usr/share/man/man1/bsqldb.1.gz|| ||/usr/share/man/man1/freebcp.1.gz|| ||/usr/share/man/man1/fisql.1.gz|| ||/usr/share/man/man1/bsqlodbc.1.gz|| | So, I guess that a solution would have to do with somehow making sqlrelay's autoconf configuration/bootstrap files aware of the '/usr/lib/x86_64-linux-gnu' path.|| Thanks. |
|
From: David M. <dav...@fi...> - 2013-01-16 19:36:57
|
Weird. I don't see anything unusual in the configure output or config.log except for the lack of ANSI C header files, and in that case, the configure script failed to write out a test program for some reason. Could you post the list of files in the freetds and freetds-dev packages? Maybe that will shed some light on the issue. Dave On 01/16/2013 09:02 AM, Petros Moisiadis wrote: > On 15/01/2013 10:47 μμ, David Muse wrote: >> Hmm... >> >> If you can, try installing libtool, automake and autoconf, then run >> ./autogen.sh inside of the sqlrelay distro and then ./configure again. >> It's possible that some things have changed on Wheezy that make the >> included configure script fail in odd ways, but that when the configure >> script is regenerated on Wheezy, it works. >> >> I ran into issues like that with Ubuntu way back. Ubuntu uses dash >> instead of bash for /bin/sh and autoconf from Fedora 13 (or so) created >> a configure script that wasn't compatible with dash, but if I used >> autoconf on Ubuntu, it worked. >> >> This could be something similar. >> >> Dave >> > I have already done that, without any luck though. > > The output of ./autogen.sh: > libtoolize: putting auxiliary files in `.'. > libtoolize: copying file `./ltmain.sh' > libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.in and > libtoolize: rerunning libtoolize, to keep the correct libtool macros > in-tree. > libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am. > > ------------------------------------------------------------------------------ > Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery > and much more. Keep your Java skills current with LearnJavaNow - > 200+ hours of step-by-step video tutorials by Java experts. > SALE $49.99 this month only -- learn more at: > http://p.sf.net/sfu/learnmore_122612 > _______________________________________________ > Sqlrelay-discussion mailing list > Sql...@li... > https://lists.sourceforge.net/lists/listinfo/sqlrelay-discussion > Ryb�+^t8��6�i:ڞ�ެ���̒@�虨� �-�x!��� 0v�^j̜om== > |
|
From: Petros M. <ern...@ya...> - 2013-01-16 14:03:00
|
On 15/01/2013 10:47 μμ, David Muse wrote: > Hmm... > > If you can, try installing libtool, automake and autoconf, then run > ./autogen.sh inside of the sqlrelay distro and then ./configure again. > It's possible that some things have changed on Wheezy that make the > included configure script fail in odd ways, but that when the configure > script is regenerated on Wheezy, it works. > > I ran into issues like that with Ubuntu way back. Ubuntu uses dash > instead of bash for /bin/sh and autoconf from Fedora 13 (or so) created > a configure script that wasn't compatible with dash, but if I used > autoconf on Ubuntu, it worked. > > This could be something similar. > > Dave > I have already done that, without any luck though. The output of ./autogen.sh: libtoolize: putting auxiliary files in `.'. libtoolize: copying file `./ltmain.sh' libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.in and libtoolize: rerunning libtoolize, to keep the correct libtool macros in-tree. libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am. |
|
From: David M. <dav...@fi...> - 2013-01-15 20:48:05
|
Hmm... If you can, try installing libtool, automake and autoconf, then run ./autogen.sh inside of the sqlrelay distro and then ./configure again. It's possible that some things have changed on Wheezy that make the included configure script fail in odd ways, but that when the configure script is regenerated on Wheezy, it works. I ran into issues like that with Ubuntu way back. Ubuntu uses dash instead of bash for /bin/sh and autoconf from Fedora 13 (or so) created a configure script that wasn't compatible with dash, but if I used autoconf on Ubuntu, it worked. This could be something similar. Dave On 01/15/2013 03:00 PM, Petros Moisiadis wrote: > On 15/01/2013 09:02 μμ, Petros Moisiadis wrote: >> >> Well, I also noticed other strange check results in the logs (eg. >> 'checking for ANSI C header files... no'). I' m attaching the logs. >> >> Thanks. >> > > Well, maybe that 'checking for ANSI C header files... no' is not that > strange... > However, I tried, on Debian, the configure script of another software > that needs odbc too, and the library was detected normally. > I also tried sqlrelay's configure script on a system with Archlinux and > the installed libraries were detected normally too. > So, I suppose the problem has to do only sqlrelay on Debian (Wheezy). > > Thanks. > > ------------------------------------------------------------------------------ > Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS > and more. Get SQL Server skills now (including 2012) with LearnDevNow - > 200+ hours of step-by-step video tutorials by Microsoft MVPs and experts. > SALE $99.99 this month only - learn more at: > http://p.sf.net/sfu/learnmore_122512 > _______________________________________________ > Sqlrelay-discussion mailing list > Sql...@li... > https://lists.sourceforge.net/lists/listinfo/sqlrelay-discussion > Ryb�+^t8��6�i:ڞ�ެ���̒@�虨� �-�x!��� 0v�^j̜om== > |
|
From: Petros M. <ern...@ya...> - 2013-01-15 20:00:55
|
On 15/01/2013 09:02 μμ, Petros Moisiadis wrote: > > Well, I also noticed other strange check results in the logs (eg. > 'checking for ANSI C header files... no'). I' m attaching the logs. > > Thanks. > Well, maybe that 'checking for ANSI C header files... no' is not that strange... However, I tried, on Debian, the configure script of another software that needs odbc too, and the library was detected normally. I also tried sqlrelay's configure script on a system with Archlinux and the installed libraries were detected normally too. So, I suppose the problem has to do only sqlrelay on Debian (Wheezy). Thanks. |
|
From: Petros M. <ern...@ya...> - 2013-01-15 19:02:12
|
On 15/01/2013 04:36 μμ, David Muse wrote: > Interesting. The freetds and odbc libs are under /usr on fedora and > ubuntu too, and it finds them. Something else must be going on. Could > you post the output of the configure script and attach the config.log > file that gets generated? > > Thanks. > > Dave > dav...@fi... Well, I also noticed other strange check results in the logs (eg. 'checking for ANSI C header files... no'). I' m attaching the logs. Thanks. |
|
From: Alastair M. <al...@ne...> - 2013-01-15 14:38:20
|
Hi Dave, Thanks, that has indeed sorted compilation. It now makes cleanly. I'm using unixODBC 2.3.0 at the moment. Thanks again, Al On 15 Jan 2013, at 14:33, David Muse <dav...@fi...> wrote: > Try adding: > > typedef SQLULEN SQLROWSETSIZE; > > around line 54 or so. > > Interesting problem though. Are you using unixodbc or iodbc, and what > version? > > David Muse > dav...@fi... > > On 01/15/2013 04:54 AM, Alastair Mackinlay wrote: >> Hi, >> >> I'm having a problem when compiling SQLRelay 0.49, the error is below. I'm using gcc 4.6.6 on a Centos 6.3 system. >> >> Any suggestions as to how I might resolve this would be appreciated. >> >> Regards, >> Al >> >> -- start -- >> make[3]: Entering directory `/usr/local/src/sqlrelay-0.49/src/api/odbc' >> /bin/sh ../../../libtool --mode=compile g++ -Wall -pipe -Wno-long-double -Werror -I./ -I../../../ -I../../../src/common -I../../../src/api/c++/include -I/usr/local/firstworks/include -DSQLR_VERSION=\"0.49\" -c sqlrodbc.cpp -o sqlrodbc.lo >> libtool: compile: g++ -Wall -pipe -Wno-long-double -Werror -I./ -I../../../ -I../../../src/common -I../../../src/api/c++/include -I/usr/local/firstworks/include -DSQLR_VERSION=\"0.49\" -c sqlrodbc.cpp -fPIC -DPIC -o .libs/sqlrodbc.o >> sqlrodbc.cpp:125: error: ISO C++ forbids declaration of 'SQLROWSETSIZE' with no type >> sqlrodbc.cpp:125: error: expected ';' before '*' token >> sqlrodbc.cpp: In function 'SQLRETURN SQLR_SQLAllocHandle(SQLSMALLINT, void*, void**)': >> sqlrodbc.cpp:268: error: 'struct STMT' has no member named 'rowsfetchedptr' >> sqlrodbc.cpp: In function 'SQLRETURN SQLR_Fetch(void*, SQLULEN*, SQLUSMALLINT*)': >> sqlrodbc.cpp:2376: error: 'struct STMT' has no member named 'rowsfetchedptr' >> sqlrodbc.cpp:2377: error: 'struct STMT' has no member named 'rowsfetchedptr' >> sqlrodbc.cpp: In function 'SQLRETURN SQLR_SQLSetStmtAttr(void*, SQLINTEGER, void*, SQLINTEGER)': >> sqlrodbc.cpp:4445: error: 'struct STMT' has no member named 'rowsfetchedptr' >> sqlrodbc.cpp:4445: error: 'SQLROWSETSIZE' was not declared in this scope >> sqlrodbc.cpp:4445: error: expected primary-expression before ')' token >> sqlrodbc.cpp:4445: error: expected ';' before 'value' >> cc1plus: warnings being treated as errors >> At global scope: >> cc1plus: error: unrecognized command line option "-Wno-long-double" >> make[3]: *** [sqlrodbc.lo] Error 1 >> make[3]: Leaving directory `/usr/local/src/sqlrelay-0.49/src/api/odbc' >> make[2]: *** [all] Error 2 >> make[2]: Leaving directory `/usr/local/src/sqlrelay-0.49/src/api' >> make[1]: *** [all] Error 2 >> make[1]: Leaving directory `/usr/local/src/sqlrelay-0.49/src' >> make: *** [all] Error 2 >> -- end -- >> ------------------------------------------------------------------------------ >> Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS >> and more. Get SQL Server skills now (including 2012) with LearnDevNow - >> 200+ hours of step-by-step video tutorials by Microsoft MVPs and experts. >> SALE $99.99 this month only - learn more at: >> http://p.sf.net/sfu/learnmore_122512 >> _______________________________________________ >> Sqlrelay-discussion mailing list >> Sql...@li... >> https://lists.sourceforge.net/lists/listinfo/sqlrelay-discussion >> >> >> _______________________________________________________ >> Unlimited Disk, Data Transfer, PHP/MySQL Domain Hosting >> http://www.doteasy.com >> > > ------------------------------------------------------------------------------ > Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS > and more. Get SQL Server skills now (including 2012) with LearnDevNow - > 200+ hours of step-by-step video tutorials by Microsoft MVPs and experts. > SALE $99.99 this month only - learn more at: > http://p.sf.net/sfu/learnmore_122512 > _______________________________________________ > Sqlrelay-discussion mailing list > Sql...@li... > https://lists.sourceforge.net/lists/listinfo/sqlrelay-discussion |
|
From: David M. <dav...@fi...> - 2013-01-15 14:37:07
|
Interesting. The freetds and odbc libs are under /usr on fedora and ubuntu too, and it finds them. Something else must be going on. Could you post the output of the configure script and attach the config.log file that gets generated? Thanks. Dave dav...@fi... On 01/14/2013 02:40 PM, Petros Moisiadis wrote: > Hello, > > On debian wheezy, the configure script cannot find some (optional) > dependencies such as freetds and odbc libraries. Of course, the relevant > '-dev' packages are already installed. Maybe this is irrelevant, but I > notice that both freetds and odbc libraries are packaged on Debian under > /usr, not under their own directory (e.g freetds headers are in > '/usr/include', not in '/usr/include/freetds'). I have also tried the > '--with-LIBRARY_NAME-prefix' option, but without any luck. I' m trying > with the latest sources (version 0.49). > > Has anyone built sqlrelay successfully on Debian Wheezy? > > ------------------------------------------------------------------------------ > Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, > MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current > with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft > MVPs and experts. SALE $99.99 this month only -- learn more at: > http://p.sf.net/sfu/learnmore_122412 > _______________________________________________ > Sqlrelay-discussion mailing list > Sql...@li... > https://lists.sourceforge.net/lists/listinfo/sqlrelay-discussion > > > _______________________________________________________ > Unlimited Disk, Data Transfer, PHP/MySQL Domain Hosting > http://www.doteasy.com > |
|
From: David M. <dav...@fi...> - 2013-01-15 14:33:12
|
Try adding: typedef SQLULEN SQLROWSETSIZE; around line 54 or so. Interesting problem though. Are you using unixodbc or iodbc, and what version? David Muse dav...@fi... On 01/15/2013 04:54 AM, Alastair Mackinlay wrote: > Hi, > > I'm having a problem when compiling SQLRelay 0.49, the error is below. I'm using gcc 4.6.6 on a Centos 6.3 system. > > Any suggestions as to how I might resolve this would be appreciated. > > Regards, > Al > > -- start -- > make[3]: Entering directory `/usr/local/src/sqlrelay-0.49/src/api/odbc' > /bin/sh ../../../libtool --mode=compile g++ -Wall -pipe -Wno-long-double -Werror -I./ -I../../../ -I../../../src/common -I../../../src/api/c++/include -I/usr/local/firstworks/include -DSQLR_VERSION=\"0.49\" -c sqlrodbc.cpp -o sqlrodbc.lo > libtool: compile: g++ -Wall -pipe -Wno-long-double -Werror -I./ -I../../../ -I../../../src/common -I../../../src/api/c++/include -I/usr/local/firstworks/include -DSQLR_VERSION=\"0.49\" -c sqlrodbc.cpp -fPIC -DPIC -o .libs/sqlrodbc.o > sqlrodbc.cpp:125: error: ISO C++ forbids declaration of 'SQLROWSETSIZE' with no type > sqlrodbc.cpp:125: error: expected ';' before '*' token > sqlrodbc.cpp: In function 'SQLRETURN SQLR_SQLAllocHandle(SQLSMALLINT, void*, void**)': > sqlrodbc.cpp:268: error: 'struct STMT' has no member named 'rowsfetchedptr' > sqlrodbc.cpp: In function 'SQLRETURN SQLR_Fetch(void*, SQLULEN*, SQLUSMALLINT*)': > sqlrodbc.cpp:2376: error: 'struct STMT' has no member named 'rowsfetchedptr' > sqlrodbc.cpp:2377: error: 'struct STMT' has no member named 'rowsfetchedptr' > sqlrodbc.cpp: In function 'SQLRETURN SQLR_SQLSetStmtAttr(void*, SQLINTEGER, void*, SQLINTEGER)': > sqlrodbc.cpp:4445: error: 'struct STMT' has no member named 'rowsfetchedptr' > sqlrodbc.cpp:4445: error: 'SQLROWSETSIZE' was not declared in this scope > sqlrodbc.cpp:4445: error: expected primary-expression before ')' token > sqlrodbc.cpp:4445: error: expected ';' before 'value' > cc1plus: warnings being treated as errors > At global scope: > cc1plus: error: unrecognized command line option "-Wno-long-double" > make[3]: *** [sqlrodbc.lo] Error 1 > make[3]: Leaving directory `/usr/local/src/sqlrelay-0.49/src/api/odbc' > make[2]: *** [all] Error 2 > make[2]: Leaving directory `/usr/local/src/sqlrelay-0.49/src/api' > make[1]: *** [all] Error 2 > make[1]: Leaving directory `/usr/local/src/sqlrelay-0.49/src' > make: *** [all] Error 2 > -- end -- > ------------------------------------------------------------------------------ > Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS > and more. Get SQL Server skills now (including 2012) with LearnDevNow - > 200+ hours of step-by-step video tutorials by Microsoft MVPs and experts. > SALE $99.99 this month only - learn more at: > http://p.sf.net/sfu/learnmore_122512 > _______________________________________________ > Sqlrelay-discussion mailing list > Sql...@li... > https://lists.sourceforge.net/lists/listinfo/sqlrelay-discussion > > > _______________________________________________________ > Unlimited Disk, Data Transfer, PHP/MySQL Domain Hosting > http://www.doteasy.com > |
|
From: Alastair M. <al...@ne...> - 2013-01-15 10:16:40
|
Hi, I'm having a problem when compiling SQLRelay 0.49, the error is below. I'm using gcc 4.6.6 on a Centos 6.3 system. Any suggestions as to how I might resolve this would be appreciated. Regards, Al -- start -- make[3]: Entering directory `/usr/local/src/sqlrelay-0.49/src/api/odbc' /bin/sh ../../../libtool --mode=compile g++ -Wall -pipe -Wno-long-double -Werror -I./ -I../../../ -I../../../src/common -I../../../src/api/c++/include -I/usr/local/firstworks/include -DSQLR_VERSION=\"0.49\" -c sqlrodbc.cpp -o sqlrodbc.lo libtool: compile: g++ -Wall -pipe -Wno-long-double -Werror -I./ -I../../../ -I../../../src/common -I../../../src/api/c++/include -I/usr/local/firstworks/include -DSQLR_VERSION=\"0.49\" -c sqlrodbc.cpp -fPIC -DPIC -o .libs/sqlrodbc.o sqlrodbc.cpp:125: error: ISO C++ forbids declaration of 'SQLROWSETSIZE' with no type sqlrodbc.cpp:125: error: expected ';' before '*' token sqlrodbc.cpp: In function 'SQLRETURN SQLR_SQLAllocHandle(SQLSMALLINT, void*, void**)': sqlrodbc.cpp:268: error: 'struct STMT' has no member named 'rowsfetchedptr' sqlrodbc.cpp: In function 'SQLRETURN SQLR_Fetch(void*, SQLULEN*, SQLUSMALLINT*)': sqlrodbc.cpp:2376: error: 'struct STMT' has no member named 'rowsfetchedptr' sqlrodbc.cpp:2377: error: 'struct STMT' has no member named 'rowsfetchedptr' sqlrodbc.cpp: In function 'SQLRETURN SQLR_SQLSetStmtAttr(void*, SQLINTEGER, void*, SQLINTEGER)': sqlrodbc.cpp:4445: error: 'struct STMT' has no member named 'rowsfetchedptr' sqlrodbc.cpp:4445: error: 'SQLROWSETSIZE' was not declared in this scope sqlrodbc.cpp:4445: error: expected primary-expression before ')' token sqlrodbc.cpp:4445: error: expected ';' before 'value' cc1plus: warnings being treated as errors At global scope: cc1plus: error: unrecognized command line option "-Wno-long-double" make[3]: *** [sqlrodbc.lo] Error 1 make[3]: Leaving directory `/usr/local/src/sqlrelay-0.49/src/api/odbc' make[2]: *** [all] Error 2 make[2]: Leaving directory `/usr/local/src/sqlrelay-0.49/src/api' make[1]: *** [all] Error 2 make[1]: Leaving directory `/usr/local/src/sqlrelay-0.49/src' make: *** [all] Error 2 -- end -- |
|
From: Petros M. <ern...@ya...> - 2013-01-14 19:54:12
|
Hello, On debian wheezy, the configure script cannot find some (optional) dependencies such as freetds and odbc libraries. Of course, the relevant '-dev' packages are already installed. Maybe this is irrelevant, but I notice that both freetds and odbc libraries are packaged on Debian under /usr, not under their own directory (e.g freetds headers are in '/usr/include', not in '/usr/include/freetds'). I have also tried the '--with-LIBRARY_NAME-prefix' option, but without any luck. I' m trying with the latest sources (version 0.49). Has anyone built sqlrelay successfully on Debian Wheezy? |
|
From: tyju t. <jck...@ya...> - 2013-01-09 19:23:39
|
http://aldareissilva.com/arrestauntcraigmartin/ |
|
From: David M. <dav...@fi...> - 2013-01-01 04:29:49
|
I forgot to mention. Rudiments - 0.40 is also out and required to build SQL Relay - 0.49. That's all. Dave dav...@fi... |
|
From: David M. <dav...@fi...> - 2013-01-01 04:00:56
|
Hello all, SQL Relay 0.49 is now available. This release features the addition of extension modules for password encryption and logging. Logging was actually added in the previous release but it has been expanded and documented in this release. The build process has been improved as well. Lots of code was reorganized to be easier to maintain and to compile faster. For many years the configure script would erroneously include "-pthread" in the compile commands on platforms that don't support it. That has been fixed. -Werror has been added to default build for most components as well and various issues revealed by it have been fixed. The windows make.bat script has been refactored too and now supports both regular and CLR builds. The client-server protocol has been refactored to improve performance. Two client-server round trips have been removed. One after authentication and another after the listener-connection handoff. All client-server commands can run in a single round trip now. The handoff="reconnect" parameter has been replaced with handoff="proxy". In the past, if handoff="reconnect" then the client was told to disconnect from the listener and reconnect to an available connection daemon. Now, if handoff="pass" is unsupported, the listener just proxies the client, ferrying data back and forth between it and the server. This causes the listener/connection relationship to be completely transparent to the client and removes a client-server round-trip. An very primitive ODBC driver has long been included in the source tree. It has been improved significantly in this release and can now be used with the isql program included with unixODBC and iODBC and with the henplus JDBC client using the JDBC-ODBC bridge. The driver still lacks many features, hasn't been tested much beyond those clients, and doesn't work on Windows without manually adding registry entries, but it is usable and should eventually make it possible to use SQL Relay with a much wider range of applications. A few bugs were fixed as well including a bug that could cause problems when fetching from an output bind cursor under a very specific set of circumstances and a bug that could cause a hang if the database login failed. Client API methods for getting the database's host name and IP address have been added as well. Give it a try and report and bugs you find. David Muse dav...@fi... |
|
From: David M. <dav...@fi...> - 2012-12-12 03:22:32
|
Ahhh, yeah, that would do it. It is interesting that you're able to get 38 connections to start in 5 seconds though. I'll have to run some tests myself. I know that the connection delay has gotten better over the years, but it isn't that fast for me here. Maybe I need to do some tuning myself :) Dave On 12/11/2012 01:02 PM, Marcus Mönnig wrote: > Hi David, > > thanks for taking the time to answer. I really appreciate it! > > I was gathering some debug files to show that it is a client side > problem, not an Oracle DB problem, when I noticed that even Oracle > SQL*Plus connections from the sqlrelay Linux host show the 10 second > delay. > > Turns out, I had an outdated second nameserver entry in resolv.conf. Grmpf... > > My 38 sqlrelay connections now start in like 5 seconds. :-) > > Thanks again and keep up the good work! > Marcus > > ------------------------------------------------------------------------------ > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial > Remotely access PCs and mobile devices and provide instant support > Improve your efficiency, and focus on delivering more value-add services > Discover what IT Professionals Know. Rescue delivers > http://p.sf.net/sfu/logmein_12329d2d > _______________________________________________ > Sqlrelay-discussion mailing list > Sql...@li... > https://lists.sourceforge.net/lists/listinfo/sqlrelay-discussion > > > _______________________________________________________ > Unlimited Disk, Data Transfer, PHP/MySQL Domain Hosting > http://www.doteasy.com > |
|
From: Marcus M. <mm...@ma...> - 2012-12-11 18:03:02
|
Hi David, thanks for taking the time to answer. I really appreciate it! I was gathering some debug files to show that it is a client side problem, not an Oracle DB problem, when I noticed that even Oracle SQL*Plus connections from the sqlrelay Linux host show the 10 second delay. Turns out, I had an outdated second nameserver entry in resolv.conf. Grmpf... My 38 sqlrelay connections now start in like 5 seconds. :-) Thanks again and keep up the good work! Marcus |
|
From: David M. <dav...@fi...> - 2012-12-11 16:23:51
|
At once time, there was a 1-second delay after starting each sqlr-connection daemon. This has been removed as of version 0.47, I think. So, that delay is gone now. It can take a long time to log into Oracle though. This is the issue that SQL Relay was originally designed to remedy. In a web-app where each page has to log in, each web page would suffer that delay if it had to log directly in to Oracle rather than logging into relay and being handed an already-open connection. You can do some general tuning to the machine Oracle is running on to make Oracle run better, and reduce the connection delay as a side effect, but it generally takes a second or two at best to log in, and usually longer. The thing that seems to have the absolute biggest impact on Oracle performance, or performance for any db, is whether the db machine has enough physical memory. Oracle has a million tunable parameters - mainly buffer sizes. Making them larger generally improves performance, so people generally try to make them as large as possible, but it's possible to make them so large that they cause all of physical memory to be consumed, then you suddenly get a drastic reduction in performance. If you're running Oracle in a VM, then there's an even worse thing that can happen. If the host machine is out of physical memory and paging, but the VM itself isn't, then an attempt by a program running in the VM to load a page from what it thinks is physical memory might actually cause that page to have to be loaded from disk on the host. If the OS running in the VM knew that it was loading the page from disk, then it could put the process to sleep while the I/O was occurring, but since the OS in the VM thinks it's loading from physical memory, the process won't sleep while waiting on the I/O and the VM has to do tricks, like insert no-ops or even put the entire VM process to sleep, or a combination. At least that's my understanding of it. Whatever is happening, it REALLY slows things down. I hope this helps. Dave dav...@fi... On 12/11/2012 06:31 AM, Marcus Mönnig wrote: > Hello! > > Is there anything that can be done/configured to speed up the start of > sqlrelay? > > A single sqlr-start against an Oracle database takes pretty exactly 10 > seconds and since I need to start 38 relays at once, this sums up to > over 6 minutes, which is a bit long. > > Kind regards, > Marcus Mönnig > > > ------------------------------------------------------------------------------ > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial > Remotely access PCs and mobile devices and provide instant support > Improve your efficiency, and focus on delivering more value-add services > Discover what IT Professionals Know. Rescue delivers > http://p.sf.net/sfu/logmein_12329d2d > > _______________________________________________________ > Unlimited Disk, Data Transfer, PHP/MySQL Domain Hosting > http://www.doteasy.com > > > > _______________________________________________ > Sqlrelay-discussion mailing list > Sql...@li... > https://lists.sourceforge.net/lists/listinfo/sqlrelay-discussion > > > _______________________________________________________ > Unlimited Disk, Data Transfer, PHP/MySQL Domain Hosting > http://www.doteasy.com > |
|
From: Marcus M. <mm...@ma...> - 2012-12-11 11:32:00
|
Hello! Is there anything that can be done/configured to speed up the start of sqlrelay? A single sqlr-start against an Oracle database takes pretty exactly 10 seconds and since I need to start 38 relays at once, this sums up to over 6 minutes, which is a bit long. Kind regards, Marcus Mönnig |
|
From: David M. <dav...@fi...> - 2012-12-08 20:41:52
|
Hello all, SQL Relay version 0.48 is now available. This release features some major internal reorganization of the server-side software and integration of a bunch of contributed code. Outwardly, not much has changed. The most noticeable change is that the sqlr-connection-XXX programs have been replaced with a single sqlr-connection program which now loads a plugin for whichever database it needs to connect to. So, if you have monitoring programs that look for that process, you may need to update them. The next-most noticeable change is the addition of a stmtcachesize parameter to the connectstring when configuring an instance of SQL Relay to talk to Oracle. Setting this parameter to a value other than 0 enables use of Oracle's Statement Cache which can improve performance significantly. See Configuring SQL Relay on the sqlrelay website for more info on this parameter and Google "Oracle Statement Cache" for more info on that. Two changes that should improve performance somewhat have been made. There were cases where the client would tell the server to abort the result set, then wait for a response, unnecessarily, incurring the cost of an additional client-server round-trip. It no longer does this. The code for talking to Oracle used to re-prepare the query before each execution, if the bind variables had been modified. This was done to work around an issue that could come up when using OCI 8.0 or when running against 8.0 or 8i databases. Oracle has long resolved the issue though, and now the re-prepare is only done in those specific cases. Other updates and fixes include: * Integrated patches from Neowiz for: * handling for oracle errors ora-01033, ora-02067 and ora-04068 * bind validation when using the statement cache * optionally rejecting oracle queries with duplicate bind variables * sqlrconnecton::setClientInfo/getClientInfo * query logging * separate authentication and response timeouts on the client-side * environment variables for setting timeouts * sqlrelay-level errors for exceeding various bounds * improved statistics gathering * created a query logging framework * implemented the current slow query log as a plugin * implemented the neowiz query log format as a plugin * created a custom query framework * implemented the neowiz statistics gathering commands as custom queries * added a test program for triggers, translations and other extensions and obscure features * fixed several bugs in the informixtooracledates translation * added a droplocalizedtemptables trigger * added support for "global temporary" to temptableslocalize translation * removed oracletemptablespreserverowsbydefault translation - temptableslocalize is much more effective * fixed a bug that caused a "no server-side cursors" error to occur when a new session is started if cursors="0" in sqlrelay.conf Enjoy! David Muse dav...@fi... |
|
From: David M. <dav...@fi...> - 2012-12-04 16:34:36
|
Unfortunately, that is the only solution right now. I've been working on an ODBC driver for SQL Relay that could also be used with JDBC but recently I've been very busy with contract work. If you're interested, I'd be happy to develop a JDBC driver for you on a contract basis. Just email me directly and we can discuss. David Muse dav...@fi... On 12/03/2012 11:25 PM, dw...@ca... wrote: > Hi, > I have sqlrelay installed, and configured for splitting reads & writes between MySQL master and slave databases. I can run sqlrsh, and that works fine. > > What I need to do, though, is have my web application use sqlrelay. It runs under Tomcat and uses Hibernate, which uses the MySQL JDBC driver. I found this email in the archive about doing that: > http://sourceforge.net/mailarchive/message.php?msg_id=18563755 > which suggested using a PostgreSQL JDBC driver and the sqlrelay drop-in library for PostgreSQL. Is that still the best/only solution? > > Thanks, > Dwight > > ------------------------------------------------------------------------------ > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial > Remotely access PCs and mobile devices and provide instant support > Improve your efficiency, and focus on delivering more value-add services > Discover what IT Professionals Know. Rescue delivers > http://p.sf.net/sfu/logmein_12329d2d > _______________________________________________ > Sqlrelay-discussion mailing list > Sql...@li... > https://lists.sourceforge.net/lists/listinfo/sqlrelay-discussion > > > _______________________________________________________ > Unlimited Disk, Data Transfer, PHP/MySQL Domain Hosting > http://www.doteasy.com > |
16 messages has been excluded from this view by a project administrator.
