Hi, Since MaxDB PHP is ascii only, it's not possible to get an SQLDBC_NO_TOTAL (-4) indicator value - this value can occur only if UTF8 is used. Therefore, MaxDB PHP can't dump at the line you mentioned because of a negative indicator value.
Regards, Thomas Simenec SAP Labs Berlin -----Original Message----- From: Alexey Gaidukov [mailto:[EMAIL PROTECTED] Sent: Donnerstag, 8. Juni 2006 06:06 To: maxdb@lists.mysql.com Subject: Re: MaxDB 7.6.00.27 fetching UTF8 data from LONG column Sorry, I think core dumped will in line 1678 in php_maxdb.c add_assoc_stringl (return_value, result->m_cols[i].bufName, result->m_cols[i].buf, result->m_cols[i].indicator, 1); because result->m_cols[i].indicator is less then zero (-4). Schroeder, Alexander пишет: > If you used DBD 7.6.00.27 and the corresponding MaxDB release, please > send an SQLDBC trace (and if small, > the Perl example). > > Regards > Alexander > ------------------------------------------------------------------------ > *From:* Alexey Gaidukov [mailto:[EMAIL PROTECTED] > *Sent:* Dienstag, 6. Juni 2006 15:16 > *To:* Schroeder, Alexander > *Subject:* Re: MaxDB 7.6.00.27 fetching UTF8 data from LONG column > > Schroeder, Alexander пишет: >>> LONG DESCRIPTOR (maxlen=824, internpos=433, >>> infoset=(with_lock|unicode), valmode=0 (vm_datapart), valind=0, >>> valpos=130401, vallen=432) >>> >> >> A LONG of length 824 (bytes) is read from the beginning, 432 bytes fit into >> this packet (which is quite ok, I assume this is a SELECT returning some more >> data). If you enable a packet trace, you will find the 1st 432 bytes from >> position >> 130401 in the packet. >> >> There must be a follow-up 'getval' request to fetch the remaining 392 bytes, >> or, your >> application does not read the remaining bytes and is happy with the first >> part ... >> >> > Thanks. But it is not my application. It is DBD-MaxDB-7.6.00.27 > (without any of my patches) from SAP AG. > Which method of SQLDBC_C.h I can use for reading the remaining bytes? > My be an example? > > Thanks a lot, > Alexey Gaidukov. >> Regards >> Alexander >> >> >> -----Original Message----- >> From: Alexey Gaidukov [mailto:[EMAIL PROTECTED] >> Sent: Samstag, 3. Juni 2006 04:01 >> To: Sven Köhler; maxdb@lists.mysql.com >> Subject: Re: MaxDB 7.6.00.27 fetching UTF8 data from LONG column >> >> Sven Köhler пишет: >> >>>>>> I have the same problem with UTF8 as with 7.6.00.16. I try to fetch LONG >>>>>> column in UTF-8 from Perl::DBD. The first LONG column in the first row >>>>>> is fetched wrong. I have 412 symbols but SQLDBC returns only 216 >>>>>> symbols. For this column SQLDBC returns indicator == SQLDBC_NO_TOTAL. >>>>>> And the symbol in 216th position is zero. For other rows indicator is >>>>>> not equals to SQLDBC_NO_TOTAL. Only for the first row. >>>>>> >>>>>> I have no problems fetching the same data in SQL STUDIO and JDBC driver. >>>>>> Only in SQLDBC. >>>>>> >>>>>> >>>>> Have you already got an answer from the MaxDB Team? >>>>> >>>>> >>>> No any answers. >>>> >>>> >>> Is it really that deterministic? I just have to do a >>> >>> SELECT long_column FROM table >>> >>> And then i get a trucated string? >>> >>> Everything else is properly setup? (the parameters of the DBI connection >>> concerning longs) >>> >>> We have already successfully used SQLDBC from Perl and PHP to _read_ >>> LONGs from the database. Until now, nobody discovered something truncated. >>> >>> >>> >> I use DBPROCs for returning resultsets. I have truncated only the first >> row only in one DBPROC. After modifications in LONG or in DBPROC data >> the bug is not reproducable. >> >> Can somebody explain me in sqldbctrace file how many symbols in the field? >> >> LONG DESCRIPTOR (maxlen=824, internpos=433, >> infoset=(with_lock|unicode), valmode=0 (vm_datapart), valind=0, >> valpos=130401, vallen=432) >> >> vallen=432/2=216 symbols? It is not true. >> >> >> >> > -- MaxDB Discussion Mailing List For list archives: http://lists.mysql.com/maxdb To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
