php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #165 Feature request: odbc_resultlong()
Submitted: 1998-03-12 07:24 UTC Modified: 1998-04-03 02:57 UTC
From: tma at gatehouse dot dk Assigned: kara (profile)
Status: Closed Package: Feature/Change Request
PHP Version: 3.0b5 OS: Windows NT 4.0
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: tma at gatehouse dot dk
New email:
PHP Version: OS:

 

 [1998-03-12 07:24 UTC] tma at gatehouse dot dk
I have had some problems with accessing 'memo' fields via 
ODBC. These are treated as BLOBs by odbc_result(), which
means that "the contents is not returned, instead it is 
sent directly to the client". I can handle that by calling 
odbc_result() at the right time, but when the memo text 
contains HTML special chars, bad things happen.

The suggested workaround given in the PHP manual is to use 
SELECT HEX(field)..., but that is not supported by MS SQL 
Server, which is what I use. So I found another solution:
I have added the function

    string odbc_result_binary(int result_id, mixed field);

    Returns: Contents of the field. Field indices start 
    from 1. Returns contents of the requested field,
    even if the field contains binary data or is longer
    than 4096 bytes. You should probably not use this
    function if the data can contain NUL characters.

I have since found out that the function should probably 
be called odbc_resultlong() for consistency with the 
function ora_fetchlong mentioned in the wishlist for 
oracle.c.

Patch follows:

--- unified_odbc.c.orig	Sun Mar 01 20:14:58 1998
+++ unified_odbc.c	Sun Mar 01 19:25:38 1998
@@ -86,6 +86,7 @@
 	{"odbc_num_fields",	php3_uodbc_num_fields,	NULL},
 	{"odbc_num_rows",	php3_uodbc_num_rows,	NULL},
 	{"odbc_result",		php3_uodbc_result,		NULL},
+	{"odbc_result_binary",		php3_uodbc_result_binary,		NULL},
 	{"odbc_result_all",	php3_uodbc_result_all,	NULL},
 	{"odbc_rollback",	php3_uodbc_rollback,	NULL},
 /* for backwards compatibility with the older odbc module*/
@@ -1053,6 +1054,16 @@
 
 void php3_uodbc_result(INTERNAL_FUNCTION_PARAMETERS)
 {
+	php3_uodbc_do_result(INTERNAL_FUNCTION_PARAM_PASSTHRU, 0);
+}
+
+void php3_uodbc_result_binary(INTERNAL_FUNCTION_PARAMETERS)
+{
+	php3_uodbc_do_result(INTERNAL_FUNCTION_PARAM_PASSTHRU, 1);
+}
+
+void php3_uodbc_do_result(INTERNAL_FUNCTION_PARAMETERS, int binary)
+{
 	char        *field;
 	int         res_ind;
 	int         field_ind;
@@ -1136,9 +1147,10 @@
 	if (result->values[field_ind].vallen == SQL_NULL_DATA){
 		RETURN_FALSE
 	} else {
-		if (result->values[field_ind].value != NULL &&
-			result->values[field_ind].vallen != SQL_NO_TOTAL &&
-			result->values[field_ind].passthru == 0){
+		if ((result->values[field_ind].value != NULL &&
+			 result->values[field_ind].vallen != SQL_NO_TOTAL &&
+			 result->values[field_ind].passthru == 0) ||
+			binary) {
 			RETURN_STRING(result->values[field_ind].value);	
 		} else {
 			char buf[4096];
@@ -1307,7 +1319,7 @@
 	YYSTYPE *arg1, *arg2, *arg3;
 	uodbc_connection *db_conn;
 	RETCODE rc;
-	list_entry le, *index_ptr;
+	list_entry *index_ptr;
 	char *hashed_details;
 	int hashed_len, len, id;
 	UODBC_TLS_VARS;

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [1998-04-03 02:57 UTC] kara
Blobs will be truncated, if longer than 4096 bytes. See also my suggestion on php-dev regarding
long handling.
Added 2 functions for binary/long datahandling: odbc_binmode(), odbc_longreadlen().
Default settings produce the same results as before. See docs for more info.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sat Dec 21 16:01:28 2024 UTC