Regarding free at muktimedia dot com's problem.
We found a simple solution, just cast the text as ntext in your SQL statement.
SELECT cast ( field_name AS NTEXT ) AS field_name
Mark J Rubin
(PHP 4, PHP 5, PHP 7, PHP 8)
odbc_fetch_into — 一行ぶんの結果を配列に取り込む
statement結果リソース。
array結果の配列。型変換によってい配列型となるので、どんな型であっても構いません。 この配列には、添字 0 から始まるカラム番号が代入されます。
row行番号。
結果におけるカラム番号を返します。また、エラーの場合に false
を返します。
例1 odbc_fetch_into() の例
<?php
$rc = odbc_fetch_into($res_id, $my_array);
?>あるいは
<?php
$rc = odbc_fetch_into($res_id, $my_array, 2);
?>Regarding free at muktimedia dot com's problem.
We found a simple solution, just cast the text as ntext in your SQL statement.
SELECT cast ( field_name AS NTEXT ) AS field_name
Mark J RubinProblem w/ MSSQL 2000 (or 7 possibly):::::
Warning: SQL error: [Microsoft][ODBC SQL Server Driver]Invalid
Descriptor Index, SQL state S1002 in SQLGetData in ...
http://bugs.php.net/bug.php?id=18514
The above error will be seen when calling @ODBC_RESULT_ALL() on a resultset that contains a field of type 'text' (MSSQL 2K). If you see this error in @ODBC_RESULT_ALL then surely @ODBC_FETCH_INTO() will return false when the resultset contains a field of type 'text' (MSSQL 2K) - causing headaches.
WORKAROUND : change the field type to NTEXT (SQL 2K/7) - this is preferable in many cases (except DB storage space) since NTEXT is simply Unicode Text.
I tried a workaround at http://www.phpbuilder.com/mail/php-db/2001071/0240.php but this didn't work.
It appears PHP could benefit from an update to its ODBC libraries since 'text' and 'memo' fields are often used in Win32 environments...Using odbc_fetch_into() is becoming tiresome when it had to be changed in php version 4.0.5, 4.0.6 and 4.2.x. Also, using define() function no longer work well with 4.2.x, so define() is not reliable for odbc_fetch_into(). Time on the job to keep up with the changes is ill-advised. Turned out the better solution is to use odbc_fetch_array and not have to deal with the hassle of updating the database, web pages, etc. It is worth the time in the long run.
--clip-- (old script)
define(CUSTOMER_ID,0);
define(CUSTOMER_NAME,1);
//$rows = 1;
if (odbc_fetch_row($result))
{
//odbc_fetch_into($result,1,&$user_detail); //php 4.0.5
//odbc_fetch_into($result,$row,$user_detail); //php 4.0.6
odbc_fetch_into($result,$user_detail,1); //php 4.2.x
echo $user_detail[CUSTOMER_ID];
} else {
echo "Failed!";
}
--clip--
//#########################################
--clip-- (new script)
if (odbc_fetch_row($result))
{
while($user_detail = odbc_fetch_array($result) ) {
echo $user_detail[CUSTOMER_ID];
}
} else {
echo "Failed!";
}
--clip--
This is pretty useful when we keep adding columns to the database table. If you combine two tables and have two columns with the same column name, then you'll need to have two seperate array, like $user_detail1 and $user_detail2, etc. Whatever you can come up with.Most annoyingly with PHP 4.0.6, the new "feature" regarding the requirement of the row number to be non-constant means that this code no longer works:
$row_num = 1; $row = array();
while (odbc_fetch_into($result, $row_num++, $row) {
// Stuff
}
So if you were wondering why, that's why. This infuriated me above all other issues I've had with PHP when I upgraded to 4.0.6
Luckily the workaround is easy enough. Just use $row_num in the odbc_fetch_into() and add $row_num++ inside the while loop. But it's still very annoying! I haven't found any other functions where this is an issue..(Win32) When calling this function against an Access 97 table, if the second parameter is passed in as the row you wish to retrieve, it APPEARS you will keep getting the same row back, regardless of the value passed in. Solution: Don't pass in the second parameter and everything autoincrements just fine.This function interacts with odbc_result in that it appears to increment the internal record pointer for the current query result. Thus if you use this function and desire to have the record you just fetched available for use in odbc_result; you'll have to call odbc_fetch_result again with the current row number. This behavior can be especially confusing if your query result contains a single record. When this is the case, use of odbc_fetch_into appears to break odbc_result.It returns FALSE if there was an error reading the row but also when there aren't more rows available.DON'T START AT ROW 0
When using odbc_fetch_into($id,$row_num,$array) don't intialize the $row_num=0.
Why... well if you do this and you have one record in the table you'll get an error... not a problem. BUT, if you have more than one row in the table, there is no error and the first record in the table is lost.
This may seem obvious, but remember that we count many things starting from 0, so doing it here made sense in my mind. Took quite some time to solve the problem, because I had used the same method on another page, where there were multiple row records, and that page worked fine. I just never noticed that it failed to print the first record's information. So you can imagine my puzzlement when the code worked on one page and not the next.Going from php 4.0.5 to php 4.0.6, the following syntax nolonger works:
odbc_fetch_into($result,$start-1,&$fields);
In 4.0.5 it works, in 4.0.6 it produces this error:
Only variables can be passed by reference
The following lines DO work however:
$tmp=$start-1;
odbc_fetch_into($result,$tmp,&$fields);Here is a very simple mehod to dump SQL results into an array that can be edited and manipulated.
==============================================
//Create the array:
$row = array();
while (odbc_fetch_into($res, $row, ODBC_NUM)) {
array_push($stuff,$row);
}
//The results are now in an array. To display the array as an HTML table we can use the following:
foreach($stuff as $line){
echo "<tr>\n";
foreach($line as $field){
echo "<td>".$field."</td>\n";
}
}
==============================================
Using this method allows a person to control individual data elements in each row and field. I am far more familiar with ASP and the getrows function but this is the closest equivalent that I have been able to find.
I good friend and co-worker was able to determine how to get this to work. Thanks Robby.