Re: [Virtuoso-users] ADO.NET provider DateTime bug(?)

2010-04-15 Thread Alexander Sidorov
I hope Virtuoso Mars Edition will solve crossplanets timezones synchronization :) 2010/4/16 Ivan Mikhailov > Hello Alexander, > > I will check details with other developers tomorrow. By default ODBC > prints strings without timezone offsets and ODBC TIMESTAMP_STRUCT lacks > timezone offset even

Re: [Virtuoso-users] ADO.NET provider DateTime bug(?)

2010-04-15 Thread Ivan Mikhailov
Hello Alexander, I will check details with other developers tomorrow. By default ODBC prints strings without timezone offsets and ODBC TIMESTAMP_STRUCT lacks timezone offset even in latest versions but I hope that there's some method to pass both TIMESTAMP_STRUCT content and the timezone offset.

Re: [Virtuoso-users] lod.openlinksw.com/sparql LIMIT not working correctly

2010-04-15 Thread Jens Lehmann
Hello, Ivan Mikhailov schrieb: Hello Jens, there is a potential problem at the LOD SPARQL endpoint. To reproduce, go to http://lod.openlinksw.com/sparql and pose query "SELECT * WHERE {?s ?p ?o} LIMIT 1". This returns 8 results instead of 1. Yes we know about this (recent) problem and try

Re: [Virtuoso-users] ADO.NET provider DateTime bug(?)

2010-04-15 Thread Patrick van Kleef
HI Alexander, Previously I stored DateTime values as strings and casted them to xsd:dateTime dynamically at query time. Then according to Ivan's advice I reimplemented SPARUL part to cast DateTime values when they are added to the store. But now ADO.NET provider returns xsd:date

[Virtuoso-users] ADO.NET provider DateTime bug(?)

2010-04-15 Thread Alexander Sidorov
Hello! Previously I stored DateTime values as strings and casted them to xsd:dateTime dynamically at query time. Then according to Ivan's advice I reimplemented SPARUL part to cast DateTime values when they are added to the store. But now ADO.NET provider returns xsd:dateTime values as strings wit

Re: [Virtuoso-users] quickest way to migrate data from 5 to 6?

2010-04-15 Thread Mitko Iliev
Hi Nathan, The RDF data should be migrated as in article already listed, this is proven to work. As for other tables i can suggest you to try dumping separate tables using the 'dbdump' utility; it is built in /binsrc/tests on unix platforms; start executable to get it's help. for DAV you sho