Re: List tables in MS Access
On Mon, 2006-09-11 at 13:05 -0400, Berthold, Scott wrote: > How can I list all of the table names in an access database? > > Thanks, > Scott Berthold Have you tried the table_info method? Martin -- Martin J. Evans Easysoft Limited http://www.easysoft.com
List tables in MS Access
How can I list all of the table names in an access database? Thanks, Scott Berthold
Re: trouble loading DBD sybase, 1_07_01
I had tried that; I loaded the 64 bit OCS libs and retried the build; This eliminated any obvious errors from the make, but the make test failed miserably. I then did a clean install of ocs for sybase 15 and applied the latest 64 bit ebf over that; I appled the DBD install and it worked. I am not sure what happened here. Thanks. I also have a 32 linux redhat, update 4 running on a i686 platform (this is not 64 bit; but 32 bit) I am runnng 32 bit sybase 15.0 on that system. the make works, but the make test fails. I will try doing a clean install of the ocs component and see what happens. I will get back to you. [EMAIL PROTECTED] wrote: You are trying to link 32bit code with 64bit code. You either need to get the 64bit version of the Sybase client libraries, or rebuild perl in 32bit mode. Michael Extranet [EMAIL PROTECTED] - 09/09/2006 00:48 To:dbi-users cc: Subject:trouble loading DBD sybase, 1_07_01 Hi, I am trying to load DBD sybase on linux I am using RedHat 4, update 4 for x64_68 platform on an EM_64T machine. My updates are current. I am tying to load DBDSybase 1_07_01 (1_07 didn't work either) I am running a 32 bit version of sybase. I tried loading a 64 version of the middleware..this just created different errors. Here is the terminal output of pearl Makefile.pl and make.. [EMAIL PROTECTED] DBD_install]$ cd DBD-Sybase-1.07_01 [EMAIL PROTECTED] DBD-Sybase-1.07_01]$ ls BUGS dbdimp.hMakefile.PL README Sybase.pm CHANGES dbd-sybase.pod MANIFEST README.freetds Sybase.xs CONFIGdbivport.h META.yml README.vms t dbdimp.c eg PWD.factory Sybase.h [EMAIL PROTECTED] DBD-Sybase-1.07_01]$ perl Makefile.PL Sybase OpenClient 15.0 found. By default DBD::Sybase 1.05 and later use the 'CHAINED' mode (where available) when 'AutoCommit' is turned off. Versions 1.04 and older instead managed the transactions explicitly with a 'BEGIN TRAN' before the first DML statement. Using the 'CHAINED' mode is preferable as it is the way that Sybase implements AutoCommit handling for both its ODBC and JDBC drivers. Use 'CHAINED' mode by default (Y/N) [Y]: N Running in threaded mode - looking for _r libraries... Found -lsybct_r for -lsybct Found -lsybcs_r for -lsybcs Found -lsybtcl_r for -lsybtcl Found -lsybcomn_r for -lsybcomn Found -lsybintl_r for -lsybintl Found -lsybblk_r for -lsybblk Running in 64bit mode - looking for '64' libraries... BLK api available - found: sybblk_r The DBD::Sybase module need access to a Sybase server to run the tests. To clear an entry please enter 'undef' Sybase server to use (default: SYBASE): User ID to log in to Sybase (default: sa): Password (default: undef): x Sybase database to use on sa (default: undef): x * Writing login information, including password, to file PWD. Checking if your kit is complete... Looks good Multiple copies of Driver.xst found in: /usr/lib64/perl5/site_perl/5.8.5/x86_64- linux-thread-multi/auto/DBI/ /usr/lib64/perl5/vendor_perl/5.8.5/x86_64-linux-thr ead-multi/auto/DBI/ at Makefile.PL line 59 Using DBI 1.50 (for perl 5.008005 on x86_64-linux-thread-multi) installed in /us r/lib64/perl5/site_perl/5.8.5/x86_64-linux-thread-multi/auto/DBI/ Writing Makefile for DBD::Sybase [EMAIL PROTECTED] DBD-Sybase-1.07_01]$ make cp dbd-sybase.pod blib/lib/DBD/dbd-sybase.pod cp Sybase.pm blib/lib/DBD/Sybase.pm /usr/bin/perl -p -e "s/~DRIVER~/Sybase/g" /usr/lib64/perl5/site_perl/5.8.5/x86_6 4-linux-thread-multi/auto/DBI//Driver.xst > Sybase.xsi /usr/bin/perl /usr/lib/perl5/5.8.5/ExtUtils/xsubpp -typemap /usr/lib/perl5/5.8. 5/ExtUtils/typemap Sybase.xs > Sybase.xsc && mv Sybase.xsc Sybase.c gcc -c -I/opt/sybase_15_0_1/OCS-15_0/include -DNO_CHAINED_TRAN=1 -DSYB_LP64 -I/ usr/lib64/perl5/site_perl/5.8.5/x86_64-linux-thread-multi/auto/DBI -D_REENTRANT -D_GNU_SOURCE -DDEBUGGING -fno-strict-aliasing -pipe -I/usr/local/include -D_LAR GEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm -O2 -g -pipe -m64 -DV ERSION=\"1.07_01\" -DXS_VERSION=\"1.07_01\" -fPIC "-I/usr/lib64/perl5/5.8.5/x86_ 64-linux-thread-multi/CORE" Sybase.c gcc -c -I/opt/sybase_15_0_1/OCS-15_0/include -DNO_CHAINED_TRAN=1 -DSYB_LP64 -I/ usr/lib64/perl5/site_perl/5.8.5/x86_64-linux-thread-multi/auto/DBI -D_REENTRANT -D_GNU_SOURCE -DDEBUGGING -fno-strict-aliasing -pipe -I/usr/local/include -D_LAR GEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm -O2 -g -pipe -m64 -DV ERSION=\"1.07_01\" -DXS_VERSION=\"1.07_01\" -fPIC "-I/usr/lib64/perl5/5.8.5/x86_ 64-linux-thread-multi/CORE" dbdimp.c dbdimp.c: In function `_dbd_rebind_ph': dbdimp.c:4807: warning: passing arg 2 of `to_binary' from incompatible pointer t ype Running Mkbootstrap for DBD::Sybase () chmod 644 Sybase.bs rm -f blib/arch/auto/DBD/Sybase/Sybase.so gcc -L/opt/sybase_15_0_1/OCS-15_0/lib -shared Sybase.o dbdimp.o -o blib/arch/a uto/DBD/Sybase/Sybase.so -L/opt/sybase_15_0_1/OCS-15_0/lib -lsybct_r -lsybcs_r -lsybtcl_r -lsyb
Re: Memory access problem with DBI or DBD-Mysql?
Hi Patrick, I have seen that version 3.0007 has been released and it (should) have fixed that bug. But... 1) In mysql_st_internal_execute() the "bind_type_guessing" variable is correctly set, but then it's NOT used: "imp_dbh->bind_type_guessing" is still used! 2) mysql_st_internal_execute() is used in only two places. Instead of doing all that tests at the beginning of the function to handle both cases (STH and DBH for the "h" parameter), why don't you change the type of the first parameter into a "imp_dbh"? Wouldn't everything be clearer this way? Bye. Federico Giannici wrote: Hi Patrick, are there any news about this bug? Someone made me notice that there a few other "tickets" open on this bug (under i386 and amd64), like this one: http://rt.cpan.org/Public/Bug/Display.html?id=20868 Thanks. Patrick Galbraith wrote: Federico, That may be the issue. I have encountered this issue in other parts of the driver. There is a better way to do this, and I can look at making sure what is being passed is the same data object. Thanks! Patrick Federico Giannici wrote: Since there has been no reply to my previous message, I have done further investigations trying to find the problem. Please note that my knowledge of DBI/DBD is almost null, so the followings are only simple suppositions. I have seen that mysql_st_internal_execute() function is executed by both the "do" and "execute" methods. It seems that the problems are only with the "do" method and not with the "execute", so I looked for the differences between them. The main difference seems to be that "execute" passes a STATEMENT handle as first argument, while "do" passes a DATABASE handle. The mysql_st_internal_execute() function uses this handle to obtain the sth and then from this one the dbh. So, my hypothesis is that if the initial handle is a database one, the sth (and the derived dbh) obtained from this is not a valid one! Anybody can confirm (or negate) this wild hypothesis? Thanks. P.S. I want to repeat that the problem manifest itself only under OpenBSD because of it's memory management that cause the program to segfault if try to access a non allocated memory. In other operating systems, a random value is get for "imp_dbh->bind_type_guessing", which is almost irrelevant. Federico Giannici wrote: It seems to me that there is some kind of memory access problem with DBI or DBD-Mysql. I'm using OpenBSD 3.9-stable amd64. On OpenBSD 3.3 i386 the problem didn't appeared. As you may know, recent version of OpenBSD have a new kind of memory handling that make the programs segfault when they try to access no (longer) allocated memory. I'm using DBI 1.45 and DBD-Mysql 2.9008. I tried DBI 1.52 and DBD-Mysql 3.0006, but the problems were more frequent, so I remained to the old versions. Here is the problem: frequently some "do" commands cause perl to crash with signal 11. The crashes seems to depend on a lot of factors. For example, loading more libraries could make the program to start working. I think it depends on the structure of the memory allocated to the program. Here is the "bt" output of the core dump: #0 0x5260a736 in mysql_st_internal_execute (h=0x4713b6e0, statement=0x479b7140, attribs=0x4aa5fd40, numParams=0, params=0x0, cdaPtr=0x7f7c8610, svsock=0x43c90498, use_mysql_use_result=0) at dbdimp.c:1654 #1 0x52612da3 in XS_DBD__mysql__db_do (cv=0x40970b20) at mysql.xs:222 #2 0x50ddf07b in XS_DBI_dispatch () from /usr/local/libdata/perl5/site_perl/amd64-openbsd/auto/DBI/DBI.so #3 0x4a5a1c47 in Perl_pp_entersub () at /usr/src/gnu/usr.bin/perl/pp_hot.c:2890 #4 0x4a60899e in Perl_runops_standard () at /usr/src/gnu/usr.bin/perl/run.c:37 #5 0x4a5f744d in S_run_body (oldscope=1) at /usr/src/gnu/usr.bin/perl/perl.c:1936 #6 0x4a5f7231 in perl_run (my_perl=0x45356258) at /usr/src/gnu/usr.bin/perl/perl.c:1855 #7 0x00401afe in main () I have found the problem is caused by accessing "imp_dbh->bind_type_guessing" for the call to ParseParam() inside mysql_st_internal_execute(). I have verified that "imp_dbh" is NOT null, but trying to access any member make the program segfault. So maybe the pointer is a stale one? I have not enough knowledge of DBI to make more debugging. Bye. -- ___ __ |- [EMAIL PROTECTED] |ederico Giannici http://www.neomedia.it ___
DBD::mysql 3.0007 and 3.0007_1 (Dev) released!
Dear DBD::mysql users and developers, DBD::mysql version 3.0007 (stable, production) and 3.0007_1 (dev) have been released! Version 3.0007 is the production version with server-side prepare statements turned off by default, and 3.0007_1 is the development version with server-side prepare statements turned on by default. Changes in 3.0007/3.0007_1, from ChangeLog: * Make sure to call dbd_st_finish when all rows from a statement handle have been fetched. (Bug #20153, Bug# 21607, as rt.cpan.org ticket #s 20464, 21241) Jim Winstead * Patch from Steve Hay to fix bind_param to deal properly with insertion of a NULL into an INT or DOUBLE column using server-side prepare. Converted Steve's dbi.pl script to expose this problem to 40bindparam2 test. * Fix to mysql_st_internal_execute to keep from passing undefined dbh handle member (bind_type_guessing) to parse_param causing crash on OpenBSD. Reported on rt.cpan.org (#20868) by Kyle Georg, as well as info from Sam Smith and Federico Giannici * Cleaned up tests to make sure test table is dropped at end of test. Notes: * To turn ON server-side prepared statements (only in 3.0007 non-dev release), simply append ";mysql_server_prepare=1" to the connect string or via the driver handle. Server-side prepared statements are turned off (emulated) by default in 3.0007. Please refer to documentation for further details. * To turn OFF server-side prepare statements (only in 3.0007_1 dev release) to have emulated prepared statements, append ";mysql_emulated_prepare=1" in the connect string or via the driver handle. Server-side prepared statements are turned on by default in 3.0007_1. Please refer to documentation for further details. * Very soon, I intend to turn on server side prepared statement on by default. I will test this thoroughly prior to making the switch, so that users don't have any problems when upgrading, when the time comes. * This prepared statement API is only available with MySQL server versions 4.1 and above, so if you're using an older version, you won't notice anything. Though, be assured that even for the driver emulated handling of prepared statements, I will continue to make sure the code is improved. As the community, one think you can do if you are interested in helping is to turn on server side prepare statements in 3.0007, or try the development driver, 3.0007_1 to see if there are any problems. I've tested the code as much as I can, but I know nothing tests code like 1000s of developers thinking of unique ways of using the driver that I never could have imagined. If you find a bug, please report it to me, or at http://bugs.mysql.com. There is also the rt.cpan.org website for reporting issues, but I prefer http://bugs.mysql.com, since there is a good verification process when a bug is reported there, and it's more visible to me. Coveat: Please make sure you don't use a threaded Perl with this driver on Solaris. Again, if anyone has any problems or questions with the driver, please feel free to email me, or especially post to dbi-users@perl.org , and if you find bugs, please report them to http://bugs.mysql.com These versions for this module can be found at CPAN: http://search.cpan.org/dist/DBD-mysql/ Again, thanks to all who helped to report bugs for this release and provided patches. Please feel free to email me directly if you need to get my attention to something that needs attention, as well as if you feel that you would like to contribute to DBD::mysql. Also, thank you for using MySQL and DBD::mysql! Kind regards, Patrick Galbraith
