Jump to content

raphael75

Members
  • Posts

    54
  • Joined

  • Last visited

  • Days Won

    1

raphael75 last won the day on February 16 2015

raphael75 had the most liked content!

Profile Information

  • Gender
    Not Telling

raphael75's Achievements

Member

Member (2/5)

1

Reputation

  1. I don't think the "limit 3" is an issue, because this query does work: select id, name, type from Objects limit 3 I tried both single- and double-quotes and neither worked.
  2. Here are the mdbtools versions I have: mdbtools/noble,now 1.0.0+dfsg-1.2ubuntu1 amd64 [installed] odbc-mdbtools/noble,now 1.0.0+dfsg-1.2ubuntu1 amd64 [installed] There are 25 columns in the table, and 4 of them are defined as VARCHAR with a length of 16,777,216. If I try to include any of these columns that are VARCHAR [16,777,216] I get the segmentation fault or the out of memory error I posted above. The rest are all either Integer, SmallInt, Boolean, or VARCHAR that have much smaller lengths (150, 50, 70, etc.). However, some of the smaller VARCHAR fields also cause either the segmentation fault or the out of memory error. I'm not sure what's going on, but when I try to paste the image of the columns in it just shows a white box. I tried both copying & pasting the image in, and saving it as a local file and uploading, and the same thing happened in both cases.
  3. I'm using Ubuntu 24.04, PHP 8.3, and an Access database with ODBC. I have this: $user = ''; $password = ''; $conn = odbc_connect('my_db', $user, $password); echo 'conn: ';var_dump($conn); $sql = 'select id, name from Objects limit 3'; $q = odbc_prepare($conn, $sql); $success = odbc_execute($q, array()); echo 'success: ';var_dump($success); $res = odbc_exec($conn, $sql); echo 'res: ';var_dump($res); while($row = odbc_fetch_array($res)){ var_dump($row); } exit; which works perfectly. However, if I try any of the following: $sql = 'select * from Objects limit 3'; $sql = 'select objects.id, objects.name, sets.name from Objects inner join sets on sets.id = objects.setid limit 3'; $sql = 'select `objects`.`id`, `objects`.`name`, `sets`.`name` from `Objects` inner join `sets` on `sets`.`id` = `objects`.`setid` limit 3'; $sql = 'select [objects].[id], [objects].[name], [sets].[name] from [Objects] inner join [sets] on [sets].[id] = [objects].[setid] limit 3'; I get this error: Error at Line : syntax error syntax error Got no result for 'select objects.id, objects.name, sets.name from Objects inner join sets on sets.id = objects.setid limit 3' command PHP Warning: odbc_exec(): SQL error: Couldn't parse SQL , SQL state in SQLExecDirect Each attempt results in the "Couldn't parse SQL" error. I don't know how to format queries that have joins, "*", etc. for Access/ODBC/etc. to be happy. Note: I am able to run all of these queries in DBeaver and they all return correctly with no errors.
  4. UPDATE: If I modified the query from "select *..." to "select id, name..." it worked! Do you know what would cause this? Is there any way I can get "select *" to work, or could this be a bug?
  5. @requinix I added Pooling=No to the odbcinst.ini file in the [ODBC] section to look like this: [MDBTools] Description=MDBTools Driver Driver=libmdbodbc.so Setup=libmdbodbc.so #FileUsage=1 #UsageCount=1 [ODBC] Trace=yes TraceFile=/tmp/odbc.log Pooling=No and still got the segmentation fault. I was looking at other options and modified the code to try odbc_connect like this: $user = ''; $password = ''; $conn = odbc_connect('my_db', $user, $password); echo 'conn: ';var_dump($conn); $sql = 'select * from Objects limit 3'; $q = odbc_prepare($conn, $sql); $success = odbc_execute($q, array()); echo 'success: ';var_dump($success); $res = odbc_exec($conn, $sql); echo 'res: ';var_dump($res); while($row = odbc_fetch_array($res)){ var_dump($row); } exit; When I run that I get this: conn: resource(14) of type (odbc link) success: bool(true) res: resource(16) of type (odbc result) mmap() failed: [12] Cannot allocate memory mmap() failed: [12] Cannot allocate memory PHP Fatal error: Out of memory (allocated 4194304 bytes) (tried to allocate 2482716230683721760 bytes) in /home/raphael/code/get_mtg_data/import_mtg_data.php on line 17 Fatal error: Out of memory (allocated 4194304 bytes) (tried to allocate 2482716230683721760 bytes) in /home/raphael/code/get_mtg_data/import_mtg_data.php on line 17 Please let me know if you have any other ideas of things I could try. I don't know why it's trying to use all this memory. It seems like it's probably a setting somewhere?
  6. Here you go: (gdb) run myfile.php /f:"out/data__2025-05-04__22.12.12.json" Starting program: /usr/bin/php myfile.php /f:"out/data__2025-05-04__22.12.12.json" [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". warning: could not find '.gnu_debugaltlink' file for /lib/x86_64-linux-gnu/libtinfo.so.6 Program received signal SIGSEGV, Segmentation fault. Downloading source file /build/unixodbc-WNgXyL/unixodbc-2.3.12/cur/SQLConnect.c 0x00007ffff29ec0cd in CLDisconnect (connection_handle=0x555555dd19c0) at /build/unixodbc-WNgXyL/unixodbc-2.3.12/cur/SQLConnect.c:428 warning: 428 /build/unixodbc-WNgXyL/unixodbc-2.3.12/cur/SQLConnect.c: No such file or directory (gdb) bt #0 0x00007ffff29ec0cd in CLDisconnect (connection_handle=0x555555dd19c0) at /build/unixodbc-WNgXyL/unixodbc-2.3.12/cur/SQLConnect.c:428 #1 0x00007ffff2b9274b in close_pooled_connection (ptr=0x555555dd2f80) at /build/unixodbc-WNgXyL/unixodbc-2.3.12/DriverManager/SQLConnect.c:2916 #2 0x00007ffff2b9eb9a in __strip_from_pool (env=0x555555d3f630) at /build/unixodbc-WNgXyL/unixodbc-2.3.12/DriverManager/SQLConnect.c:3101 #3 __SQLFreeHandle (handle_type=<optimized out>, handle=0x555555d3f630) at /build/unixodbc-WNgXyL/unixodbc-2.3.12/DriverManager/SQLFreeHandle.c:283 #4 0x00007ffff2cecfd6 in ?? () from /usr/lib/php/20230831/pdo_odbc.so #5 0x00007ffff71adb80 in ?? () from /usr/lib/php/20230831/pdo.so #6 0x0000555555909a3f in zend_objects_store_del () #7 0x0000555555881a8e in zend_hash_reverse_apply () #8 0x000055555585b5ed in ?? () #9 0x000055555586cdbd in zend_call_destructors () #10 0x00005555557fdaed in php_request_shutdown () #11 0x000055555595f249 in ?? () #12 0x0000555555684791 in ?? () #13 0x00007ffff722a1ca in __libc_start_call_main (main=main@entry=0x555555684440, argc=argc@entry=3, argv=argv@entry=0x7fffffffda08) at ../sysdeps/nptl/libc_start_call_main.h:58 #14 0x00007ffff722a28b in __libc_start_main_impl (main=0x555555684440, argc=3, argv=0x7fffffffda08, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffd9f8) at ../csu/libc-start.c:360 #15 0x0000555555685915 in _start () (gdb) Please let me know if this looks good.
  7. @requinix I have never used gdb before, but I just went through a tutorial on how to use it with php and here is the output. Please let me know if this is what you need: (gdb) run myfile.php /f:"out/data__2025-05-04__22.12.12.json" Starting program: /usr/bin/php myfile.php /f:"out/data__2025-05-04__22.12.12.json" [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". warning: could not find '.gnu_debugaltlink' file for /lib/x86_64-linux-gnu/libtinfo.so.6 Program received signal SIGSEGV, Segmentation fault. 0x00007ffff29ec0cd in CLDisconnect (connection_handle=0x555555dd1970) at /build/unixodbc-WNgXyL/unixodbc-2.3.12/cur/SQLConnect.c:428 warning: 428 /build/unixodbc-WNgXyL/unixodbc-2.3.12/cur/SQLConnect.c: No such file or directory @Random8 I tried using the full file path and got the same error.
  8. I have Ubuntu 24.04 and php 8.3. I'm trying to connect to an Access DB through PDO ODBC running on the command line. Here is what I have enabled: $ php -i | grep PDO PDO PDO support => enabled PDO drivers => mysql, odbc PDO Driver for MySQL => enabled PDO_ODBC PDO Driver for ODBC (unixODBC) => enabled code: <?php $access_file = './myfile.mdb'; $db=new PDO('odbc:Driver=MDBTools; DBQ=' . $access_file . ';'); ?> error: Segmentation fault (core dumped) That's all I get, no other information. I am able to connect to and run queries on this mdb file with DBeaver, so the file should be ok. I haven't been able to find what would cause a Segmentation fault just by creating the PDO connection. I tried mdbtools. If I run the mdb-ver it returns "JET4". If I run mdb-sql I can run queries and they return correctly. I also tried "describe table" and it worked correctly, too. So it looks like everything is working correctly with the mdbtools. I found some old .mdb files that I created years ago for an Access class. I was able to load and run queries on them in DBeaver and work with them using mdb-tools, but again I get the Segmentation fault with them when trying to open them with PHP. It seems to be something specific to PHP.
  9. It turned out to be a non-breaking space that was on the line ($b == false) && after the 2nd &. Removing that fixed the issue.
  10. Here is my PHP code: <?php $a = 76; $b = true; $c = 0; $d = 500; $check = ( ($a > 0) && ($b == false) && ($c == 0) && ($d > 0) ); echo '[' . $check . ']' . "\n"; //echoes [] // ------------------------------- $a = 76; $b = false; $c = 0; $d = 500; $check = ( ($a > 0) && ($b == false) && ($c == 0) && ($d > 0) ); echo '[' . $check . ']' . "\n"; ?> This generates this error: PHP Fatal error: Uncaught Error: Call to undefined function () in /home/abc/code/php_test/test_boolean.php:26 Stack trace: #0 {main} thrown in /home/abc/code/php_test/test_boolean.php on line 26 I can't figure out why this error is occurring. Why does changing $b to false make it think it's a function call? I get this error if I run it in the browser or on the command line. However, testing it in different online php testers doesn't cause an error and produces the expected output. I don't know why this is causing an error on my local. I tried with both php7.3.31 and php 8.0.12
  11. Zip should support 64-bit archives. If you can't get it to work, you could try using WinRAR for Linux and call it from exec().
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.