Can you test this on W2k ? We've a bad rate at fixing w98 because it mostly turns out it's a bug in the OS.

Yes, problem persists with W2K and V4.2.1,

Gustav Graf

can you please provide a sample script and schema to reproduce this problem?

here is my sample script:
<?PHP
    echo "big db test<br>";
    $max       = 10000;

    $db   = odbc_connect ($DB, $DBAppUser, $DBAppPass) or die ("no connect");
    $res  = odbc_exec ($db, "SET TEXTSIZE ".(2 * $max));
    $res  = odbc_exec ($db, "DROP TABLE Test");
    $res  = odbc_exec (
      $db,
      "CREATE TABLE test (
        TEST_ID int NOT NULL IDENTITY PRIMARY KEY,
        TEST_TEXT ntext NULL
      )");
    $text = "";
    for ($i = 0; strlen ($text) < $max; $i++)
      $text .= "$i\n";
    echo strlen ($text)." chars written<br>";
    $res = odbc_exec ($db, "INSERT INTO Test (TEST_TEXT) VALUES ('$text')");
    $res = odbc_exec ($db, "SELECT TEST_TEXT FROM Test WHERE TEST_ID = 1");
    odbc_longreadlen ($res, $max);
    $text = odbc_result ($res, "TEST_TEXT");
    echo strlen ($text)." chars received<br>";
    echo "<listing>".htmlentities($text)."</listing>";
    echo "done";
?>

with PHP 4.2.1 I get following response:
big db test
10000 chars written
15904 chars received
0
1
2
<.. all ok until >
1039
1040
1? ?<66
1767
1768
<.. all ok until >
2220
2221
')' @?> tz0?$?t???< ??l?#?|??x?B$ 0? ?
TEST_TEXT<> (?!>0
1
2
<.. not ok double values starting again from 1>
1039
1040
1? ?<

done

with PHP 4.1.1 I get:
big db test
10000 chars written
10000 chars received
0
1
2
<.. all values ok>
2220
2221

done

maybe I make a mistake when switching PHP versions: I just rename the directories and copy the corrsponding php4ts.dll into the windows system dir (c:\windows\system on win98; c:\winnt\system32 on w2k)? Just the zlib extension is loaded.

Seeing your code my initial reaction is... NTEXT is not a valid ODBC type.  At least not in ODBC v2 which what PHP is using (it is valid in OBDC 3.5/3.7).  

Any chance you can use VARCHAR, which is a valid ODBC type?

No, I cannot change the table definitions, because they are parts of an existing application. I was very happy to find out the "SET TEXTSIZE" trick, do get access to the NTEXT columns, without that PHP was and is still crashing. 
But something must have changed from PHP version 4.1.1 to 4.2.1, that this is not working any more.

Reminds me a littlebit on that error I had with an WinXP Apache 1.3.19 installation, where I got simmilar code garbage in html results, I found a patch for apache to fix that, maybe that helps

Gustav Graf

Unfortunately I cannot test this.  My local database dies upon trying to create a table with type NTEXT via ODBC.

do you use a mssql database? then you can create the table with the mssql enterprise manager, or a can open you a mssql test access on my server, 

Gustav Graf

Please realize that while database A may support functionality MNOP, ODBC functionality is NOT assured.  

To answer the question, no I do not use an MS database.  My testing comes from using iODBC and unixODBC ODBC drivers, and Virtuoso and PostgreSQL-ODBC for functionality.  

4.1.2 seems to provide the correct output from the page.
current cvs version seems to corrupt output.

dank, i could probably give you remote access or get a debugger loaded on it tomorrow.

Paul

No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.

what kind of feedback do you need?

First of type NTEXT is not a valid ODBC v2 type.  It is valid in later versions of ODBC but we don't support them yet.   I'm waiting for some manuals to show before I finish my work on it. 

Second one thing to try that a few people have reported success with it running a sql query with this information in it: "SET TEXTSIZE <some really large number here>"  See if that works for you.  

Also there have been a few bug fixes in the latest CVS.  Feel free to try it as well, although I didn't touch any of the longreadlen code.

No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.

Sorry about late nite feedback,

but I found something new in PHP V4.2.2:
when you set odbc_longreadlen (0, $max) - with no resource id - it works fine, when you set it after the query with resulting resource id - odbc_longreadlen ($res, $max) - it failes and returns 4096 bytes less (what in my opinion is the default readlen from php.ini). see provided example:

<?PHP
    echo "big db test<br>";
    $DB        = '';
    $DBAppUser = '';
    $DBAppPass = '';
    $max       = 5000;

    $db   = odbc_connect ($DB, $DBAppUser, $DBAppPass) or die ("no connect");

##  create db

    $res  = odbc_exec ($db, "SET TEXTSIZE ".($max * 2));
    $res  = odbc_exec ($db, "DROP TABLE Test");
    $res  = odbc_exec (
      $db,
      "CREATE TABLE test (
        TEST_ID int NOT NULL IDENTITY PRIMARY KEY,
        TEST_TEXT ntext NULL
      )");
      
##  fill text

    $text = "";
    for ($i = 0; strlen ($text) <= $max; $i++)
      $text .= "$i\n";
    $text = substr ($text, 0, $max);
    echo strlen ($text)." chars written,  last $i<br>";
    $res = odbc_exec ($db, "INSERT INTO Test (TEST_TEXT) VALUES ('$text')");
    
##  read and set odbc_readlen with query result

    $res = odbc_exec ($db, "SELECT TEST_TEXT FROM Test WHERE TEST_ID = 1");
#    odbc_binmode ($res, 0);
    odbc_longreadlen ($res, $max);

    $text = odbc_result ($res, "TEST_TEXT");
    echo strlen ($text)." chars received (", strlen ($text) + 4096 , " when 4096 added)<br>";
    echo $text, "<br>";


##  read and set odbc_readlen with without result

#    odbc_binmode (0, 0);
    odbc_longreadlen (0, $max);

    $res = odbc_exec ($db, "SELECT TEST_TEXT, TEST_ID FROM Test WHERE TEST_ID = 1");
    $text = odbc_result ($res, "TEST_TEXT");
    echo strlen ($text)." chars received (", strlen ($text) + $max , " when $max added)<br>";
    echo $text, "<br>";

    echo "done";

?>

hope this gives you a clue

gustav graf

remove -'s from email to reply directly

Please try using this CVS snapshot:

  http://snaps.php.net/php4-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-latest.zip

same with win32-latest, 

maybe odbc returns a strange odbc-type, so this is handled as a non-long type and binded to the result in odbc_exec and then not read completely afterwards in odbc_result () with some kind of missinterpresting and missallocating some memory? This would explain the different results when calling odbc_longreadlen () without or with the query result.

Please try using this CVS snapshot:

  http://snaps.php.net/php4-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-latest.zip

No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.

I believe that I am experiencing this same bug with PHP 4.3.0 on WinXP Pro. I get garbage when retrieving some (it only seems to occur with large records) ntext fields from a MSSQL Server 2K DB through ODBC. I'm not using the MSSQL library because I need Unicode support which will never be implemented (according to this: http://www.phpbuilder.com/mail/php-windows/2003031/0193.php).

I need to convert the database to mySQL, which is not possible with all the garbage I'm getting from some fields. I have to import hundreds of thousands of records, and I need to be sure that the data hasn't been damaged.

Do you have any further suggestions not mentioned in this thread?

Thanks,
Jozef