On 4/16/12 1:38 PM, Will Daniels wrote:
OK forget this, it's definitely a PHP problem.

Sorry for the noise.

-Will

Yes, but we get the blame for everything :-)

Now I have to ponder about what's making Debian feel it makes sense to move away from iODBC .

Kingsley



On 16/04/12 12:37, Will Daniels wrote:
Hi,

I came across this mail from Fred Giasson in the SF list archive [1]:

Hi Everybody,

I am facing long read issue with one of my server (when sparqling). The
server runs:

(1) Virtuoso 5.12.3041
(2) PHP 5.3.2
(3) It uses the default unixodbc drivers that comes with ubuntu
(4) I am using DB.DBA.SPARQL_EVAL to wrap the sparql queries via the
PHP-ODBC API.


So, basically, the problem is that long values get truncated at 4070
bytes (which is Virtuoso's max, after this it is supposed to get into a
blob, but apparently that it has some issues reading it), and then
garbage is added after these 4070 (some kind of stack overflow) bytes.


I tested:

(1) I tested a full set of parameters in odbc_connect (the flag). To
increase the defaultlrl php.ini setting, to play with the binmode, to
use the odbc_longreadlen() api call, etc. Nothing works.
(2) I confirm that I don't have this issue when using iSql/Conductor
(probably since it uses vsp&   iodbc)


I want to know:

(1) if there is some ways to fix this using some PHP API
(2) if this is a bug, and if this has been fixed in 5.14
(3) if this will only works with iodbc drivers


Thanks!


Take care,

Fred

I'm stuck with the same problem using Virtuoso 6.1.5 on PHP 5.3 (albeit using
SQL directly, not SPARQL). Symptoms are the same, no matter what I have tried, I
simply cannot get PHP's ODBC implementation to read LONG NVARCHAR columns with
Virtuoso ODBC driver. I also get some junk at the end of the data same as Fred
describes.

I'm using PHP with unixODBC (because iODBC is apparently "going away" in Debian)
but I don't see that it ought to make any difference. If it would, I can
consider changing to iODBC, but that would be quite disruptive to my work so I'd
rather not try it just on the off-chance.

If anybody at OpenLink (or elsewhere) has any suspicions about where exactly the
problem here lies (PHP, unixODBC, Virtuoso, some connection parameter...) I can
do my part to try to patch etc. but I could really use some pointers for where
to start looking.

Cheers!
-Will

[1] https://sourceforge.net/mailarchive/message.php?msg_id=27447958

------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________
Virtuoso-users mailing list
Virtuoso-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/virtuoso-users

!DSPAM:4f8c0487161845508517005!


------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________
Virtuoso-users mailing list
Virtuoso-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/virtuoso-users



--

Regards,

Kingsley Idehen 
Founder&  CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen






Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to