Re: [sqlite] JDBC and savepoints
The Xerial JDBC driver does not if I recall correctly. There’s no reason why it couldn’t, the developers just didn’t implement it. Perhaps you should file an enhancement request in their issue tracker requesting it be implemented. If you don’t need nested transactions then you can get a single begin/commit transaction by disabling auto commit (see http://docs.oracle.com/javase/tutorial/jdbc/basics/transactions.html) Pepijn On 29 Jun 2014, at 12:15, hala wrote: > JDBC does not support savepoints from SQLite > > is there any replacement for savepoints? > > if not what to use for bulk inserts to ensure the possibility of rolling > back without losing much data? > > > > -- > View this message in context: > http://sqlite.1065341.n5.nabble.com/JDBC-and-savepoints-tp76304.html > Sent from the SQLite mailing list archive at Nabble.com. > ___ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Sqlie from c#: encoding bug?
Sounds like you're passing a non utf-8 encoded string from C# directly to sqlite. The easiest way I know of to check the actual data in the database is to dump it as hex (i.e., select hex(column_name)) and check if the contents are what you expect or not. Gut feeling is that the strings in the database will be incorrect which would mean that the problem is on the C# binding side. The problem is most likely located where the C# strings are converted to C strings. I'm not a C# user, but from the documentation it looks like you (or the binding you're using) should be calling Encoding.UTF8.GetBytes(myString) somewhere. Perhaps that's something you could check for in the code? Pepijn On 19-01-14 16:57, cinema cinema wrote: I'm reading a text from c# saving it through a insert parameter in a varchar column of a table. Both the file and the sqlite db encoding is utf-8 but I see different characters (it seems due to a bad encoding) while reading data from the sqlite3 command line or from other clients... Any suggestion? ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Does sqlite has db file-size restriction on Solaris 10?
Ah ok, I thought the Xerial driver no longer supported the nestedvm stuff. What you'll need to do is compile the Xerial binary for Solaris. See https://bitbucket.org/xerial/sqlite-jdbc/wiki/Home#BuildfromSource for details. Pepijn On 11/26/2013 06:48 AM, Liang Kunming wrote: Hi, Pepijn, After confirm and compare the content, the jdbc driver which we are using to access sqlite is from Xerial fork (https://bitbucket.org/xerial/sqlite-jdbc): sqlite-jdbc-3.7.2.jar<https://bitbucket.org/xerial/sqlite-jdbc/downloads/sqlite-jdbc-3.7.2.jar>. Do you have any other suggestion for this issue? Thanks. sqlite-jdbc-3.7.2.jar<https://bitbucket.org/xerial/sqlite-jdbc/downloads/sqlite-jdbc-3.7.2.jar> 3.1 MB 2013-01-23 48150 Regards, Liang Kunming. -Original Message- From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users-boun...@sqlite.org] On Behalf Of Liang Kunming Sent: 2013年11月25日 17:29 To: General Discussion of SQLite Database Subject: Re: [sqlite] Does sqlite has db file-size restriction on Solaris 10? Hi, Pepijn, Thanks. Please help me to do some testing and check whether the 2GB restrict issue be solved if use new driver. Regards, Liang Kunming. -Original Message- From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users-boun...@sqlite.org] On Behalf Of Pepijn Van Eeckhoudt Sent: 2013年11月25日 16:09 To: sqlite-users@sqlite.org Subject: Re: [sqlite] Does sqlite has db file-size restriction on Solaris 10? On 2013-11-23 02:03, Liang Kunming wrote: java.sql.SQLException: [SQLITE_ERROR] SQL error or missing database (no such table: tasks) at org.sqlite.DB.newSQLException(DB.java:383) at org.sqlite.DB.newSQLException(DB.java:387) at org.sqlite.DB.throwex(DB.java:374) at org.sqlite.NestedDB.prepare(NestedDB.java:134) at org.sqlite.DB.prepare(DB.java:123) NestedDB in the stack trace indicates you're using the old Zentus JDBC driver in NestedVM (http://nestedvm.ibex.org/) mode. I would first try to take that out of the equation and see if it solves the problem. To do that you'll need to compile the native library part of the Zentus driver for Solaris, but since the source code is no longer available that might be hard to do (unless you have a copy somewhere). Using the Xerial fork (https://bitbucket.org/xerial/sqlite-jdbc) is probably easier. It doesn't ship with a Solaris binary though, so you'll still need to compile that first. Pepijn ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Does sqlite has db file-size restriction on Solaris 10?
On 2013-11-23 02:03, Liang Kunming wrote: java.sql.SQLException: [SQLITE_ERROR] SQL error or missing database (no such table: tasks) at org.sqlite.DB.newSQLException(DB.java:383) at org.sqlite.DB.newSQLException(DB.java:387) at org.sqlite.DB.throwex(DB.java:374) at org.sqlite.NestedDB.prepare(NestedDB.java:134) at org.sqlite.DB.prepare(DB.java:123) NestedDB in the stack trace indicates you're using the old Zentus JDBC driver in NestedVM (http://nestedvm.ibex.org/) mode. I would first try to take that out of the equation and see if it solves the problem. To do that you'll need to compile the native library part of the Zentus driver for Solaris, but since the source code is no longer available that might be hard to do (unless you have a copy somewhere). Using the Xerial fork (https://bitbucket.org/xerial/sqlite-jdbc) is probably easier. It doesn't ship with a Solaris binary though, so you'll still need to compile that first. Pepijn ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] SQLite version 3.8.2 running 2.5x faster for some queries.
Is datetime special in thuis context or will constant expression hoisting like
this happen for any function?
Pepijn
> Op 22-nov.-2013 om 15:35 heeft Richard Hipp het volgende
> geschreven:
>
> The www.sqlite.org server logs are stored in an SQLite database (of
> course). We have a script that is run daily on that database with a dozen
> or so queries that look something like this:
>
> .print
> .print Downloads in the past 24 hours
> .mode column
> .width -6 -6 100
> .header on
> SELECT count(*) AS count, count(distinct ip) AS IPs, url
> FROM log
> WHERE date>datetime('now','-24 hours')
>AND (url GLOB '*/2013/*'
> OR url GLOB '*/snapshot/*'
> OR url GLOB '*/xfer'
> OR url GLOB '*/blob/*')
> GROUP BY url
> ORDER BY count DESC;
>
> Today's database contains 6 days worth of data, is 590MB in size, and is
> just short of 2 million records. There are no indices, so each query is a
> full table scan. Using SQLite 3.8.1, the query above took 1.793 seconds on
> a recent test run. But the code on trunk (and the latest snapshots at
> http://www.sqlite.org/download.html) took only 0.686 seconds. The
> difference is that the string constants and the datetime() function call
> are factored out of the inner loop in 3.8.2.
>
> To be fair: Our production script does not contain exactly the SQL shown
> above. Rather than using the bare datetime() call, the real script says:
> "(SELECT datetime('now','-24 hours'))". Putting the datetime() call inside
> a subquery is a trick that causes the datetime function to only be invoked
> once even without the new constant-function factoring optimization of
> 3.8.2. And with that trick, the performance difference is not nearly so
> dramatic (though 3.8.2 is still faster by about 10%). Also, the
> performance difference here would only apply to a full table scan that
> spends a lot of time looping inside of the virtual machine. There would
> not be nearly as dramatic a difference if the database held an index on the
> "log.date" column.
>
> Nevertheless, we suspect that queries like the above are common in the
> wild, and so we hope that the upcoming 3.8.2 release will make a big
> difference for some people.
>
> If you try the 3.8.2 pre-release snapshot in your application and see a
> performance improvement, we'd appreciate hearing from you.
>
> For testing and comparison purposes, the optimization that doubles the
> performance of the query above can be disabled using the following API:
>
>sqlite3_test_control(SQLITE_TESTCTRL_OPTIMIZATIONS, db, 8);
>
> where "db" is the database connection create by sqlite3_open(), or if you
> are using the command-line shell:
>
>.testctrl optimizations 8
>
> --
> D. Richard Hipp
> d...@sqlite.org
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Intended use case for 'without rowid'?
On 18 Nov 2013, at 06:13, Simon Slavin wrote: > On 18 Nov 2013, at 3:38am, Peter Aronson wrote: > >> It might be simpler to simply specify a minimum release of SQLite that must >> be supported, > > Actually this is how lots of apps specify their file format. Part of the > file header is a version number. When the API opens the file it checks to > see that its version is equal or higher to the version number encoded in the > file. If not, it presents an error message. > > This means you don't have to encode complicated logic about which file > version requires which abilities. All you need to do is compare two > versions. It's neat. That would be the ideal solution but, unless I missed it, there’s no such number in the sqlite database header that we can use for this purpose. Schema format number seems like the closest thing that you could use for this, but it wasn’t bumped with the addition of partial indices and without rowid. I guess Peter’s ‘try to open with SQLite 3.7’ heuristic is the best we’ll be able to do. The only downside of that approach is that you can’t distinguish between incompatible DDL and actual database corruption. Pepijn ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Intended use case for 'without rowid'?
> For Peter & Pepijn - I think the issue is essentially a forward-compatibility > problem moreso than a backward-compatibility one. So I think your idea on > introducing some version control would be the least painful. Indeed. The lack of rowid itself is not an issue. It's that someone could create a database using SQLite 3.8.x features, pass it on to someone with a SQLite 3.7 based app and run into runtime problems that they weren't expecting. We're looking for some way to reliably detect these kinds of cases or alternatively language to put in the spec to prevent this situation in the first place. AFAICT there's no simple value in the database we can use to check for this. I mistakenly thought we could use the schema format number for this. Queries on sqlite_master could work but we would need to come up with a way to use this reliably. The suggested queries check for known problems. I'm worried that this will be an inherently brittle check since the next sqlite revision could introduce a new feature for which the spec has no checks in place. Perhaps we should make the allowed DDL subset a part of the spec. That way we make explicit what is allowed and anything outside of that is forbidden. Pepijn ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Intended use case for 'without rowid'?
Will without rowid introduce a new schema version number? If so, we’ll be ok since GeoPackage requires schema version 4. Pepijn On 15 Nov 2013, at 16:33, Peter Aronson wrote: > One additional thing not listed in this document -- use of a internal rowid > alias (OID, ROWID or _ROWID_) will produce a parse error on a query against a > WITHOUT ROWID table (unless, of course, it has an actual column with the > specified name), which makes sense, of course, but could be an issue for > generic table handling code that currently uses any of those. > > The fact that the presence of such a table makes a database containing one > unreadable at releases before 3.8.2 is a bit of an issue for those using > SQLite as a data exchange format (like GeoPackages), but then that's true > with partial indexes too. > > Peter > > On 11/15/2013 4:47 AM, Luís Simão wrote: >> SQLite answers those question in: >> >> http://www.sqlite.org/draft/withoutrowid.html >> >> BR >> ___ >> sqlite-users mailing list >> sqlite-users@sqlite.org >> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users >> > > ___ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Intended use case for 'without rowid'?
On 15-11-13 12:47, Luís Simão wrote: SQLite answers those question in: http://www.sqlite.org/draft/withoutrowid.html Thanks for the pointer. That answered all my questions. Pepijn BR ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] Intended use case for 'without rowid'?
I've been looking into the upcoming 'without rowid' feature implementation to assess if it will have any impact on the OGC GeoPackage specification. One of the things I was wondering is what the intended use case of this feature is. Does it provide a performance boost and/or space savings? If not, when would you use this? Regards, Pepijn ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] How to use aux_data effectively?
On 07 Sep 2013, at 02:03, Peter Aronson wrote: > Ah, I see. Yeah, that would be trickier. You could save off the geometry > blob and the GEOSPreparedGeometry object in a structure passed in to > sqlite3_create_function and accessed via sqlite3_user_data and memcmp each > geometry blob with the previous one to see if you need to regenerate the > prepared geometry, but then you'd have to clean it up yourself somehow > afterwards, and the cost of alloc, memcpy calls and memcmp calls would have > to be cheaper than generating the prepared geometry. That's definitely an option; I'm already using sqlite3_user_data to store a bunch of function pointers that abstract the differences between geopackage, spatialite3 and spatialite4. It's all still pretty crude, but it's starting to get where I want it to be. Adding a fixed size LRU geometry cache to this seems like the way forward, which is essentially what spatialite has done as well. Fixed size LRU avoids the need to have cleanup routines. I would expect the memcmp to not be slower than creating the prepared geometry. Creating that object requires two converting from blob to GEOSGeometry to GEOSPreparedGeometry. I have a hard time imagining that this would be faster than one or two memcmps. Anyway, I'll experiment with this approach and profile it to see if it's worth it. Thanks for the ideas and advice. Pepijn ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] How to use aux_data effectively?
Peter,
Thanks for the suggestion but that's not the part I'm trying to optimise at the
moment. It could be useful to use auxdata there as well to avoid reparsing the
text of course. What I would really like to achieve is that the
GEOSPreparedGeometry can be cached to speed up the geometry calculations.
Pepijn
On 07 Sep 2013, at 00:58, Peter Aronson wrote:
> Actually, as it turns out, you can get the result you want by having the
> GeomFromText function use auxdata to store the geometry blob generated from
> the WKT string, since it's a constant. Then all the GeomFromText has to do
> is to return the Geometry blob when sqlite3_get_auxdata returns non-NULL.
>
> Peter
>
> - Original Message -
>> From: Pepijn Van Eeckhoudt
>> To: sqlite-users@sqlite.org
>> Cc:
>> Sent: Friday, September 6, 2013 8:38 AM
>> Subject: [sqlite] How to use aux_data effectively?
>>
>> Hi,
>>
>> In the extension I'm developing (https://bitbucket.org/luciad/libgpkg)
>> I'm currently adding support for queries like:
>> select Distance(
>> GeomFromText('Point(13.457 3)'),
>> geometry
>> ) from table;
>>
>> GeomFromText takes a string and outputs a geometry blob
>> Distance takes two geometry blobs and returns a double
>>
>> In order to speed up the distance function I was wondering if I could
>> use aux_data to cache the parsed version of the first parameter since
>> this remains the same for every call. So far I haven't been able to get
>> this to work though, aux_data is always NULL, no matter what I try.
>>
>> My hunch is that this is because the first parameter is the result of a
>> function call which could in theory return different values for each row
>> even if the input parameters are constant. Is that correct?
>>
>> Are there any other ways to kind of memoize the GeomFromText function
>> (or the parameters to distance) besides aux_data?
>>
>> Thanks,
>>
>> Pepijn
>>
>> ___
>> sqlite-users mailing list
>> sqlite-users@sqlite.org
>> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>>
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] How to use aux_data effectively?
On 06 Sep 2013, at 17:51, Simon Davies wrote:
>> Are there any other ways to kind of memoize the GeomFromText function
>> (or the parameters to distance) besides aux_data?
>
> select Distance( constGeom, geometry ) from table, (select
> GeomFromText('Point(13.457 3)') as constGeom );
I just tried this out, but unfortunately it doesn't make a difference. I guess
this boils down to the same thing as what I was doing before. table and the sub
select get joined and the function is invoked for every row again.
Or I could be doing something in wrong in my code of course. Snippet copied
below. With a simple query this prints 'Recreate' for each row.
Pepijn
disclaimer: this is just quick and dirty proof of concept code to see if this
would work or not.
static void ST_Contains(sqlite3_context *context, int nbArgs, sqlite3_value
**args) {
GEOS_START(context);
const GEOSPreparedGeometry *pg1 = sqlite3_get_auxdata(context, 0);
if (pg1 == NULL) {
printf("Recreate\n");
GEOSGeometry *g1 = GEOS_GET_GEOM( args, 0 );
if (g1 == NULL) {
sqlite3_result_error(context, error_message(&error), -1);
return;
}
pg1 = GEOSPrepare_r(GEOS_HANDLE, g1);
if (pg1 == NULL) {
sqlite3_result_error(context, error_message(&error), -1);
return;
}
} else {
printf("Reuse\n");
}
GEOSGeometry *g2 = GEOS_GET_GEOM( args, 1 );
if (g2 == NULL) {
sqlite3_result_error(context, error_message(&error), -1);
return;
}
char result = GEOSPreparedContains_r(GEOS_HANDLE, pg1, g2);
if (result == 2) {
geom_get_geos_error(&error);
sqlite3_result_error(context, error_message(&error), -1);
} else {
sqlite3_result_int(context, result);
}
GEOS_FREE_GEOM( g2 );
sqlite3_set_auxdata(context, 0, pg1, NULL);
}
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] How to use aux_data effectively?
On 06 Sep 2013, at 17:58, Dominique Devienne wrote:
>> select Distance( constGeom, geometry ) from table, (select
>> GeomFromText('Point(13.457 3)') as constGeom );
>
> Clever. Thanks for that.
Simple and elegant. Thanks for the idea, I'll give it a try.
> Or make your Distance function implementation do the GeomFromText
> implicitly, with a bit of duck-typing.
The semantics of Distance (or better ST_Distance) are defined in the ISO SQL/MM
part 3 and OGC Simple Feature/SQL specs. I would prefer to avoid non-specified
behaviour.
Pepijn
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] How to use aux_data effectively?
Hi,
In the extension I'm developing (https://bitbucket.org/luciad/libgpkg)
I'm currently adding support for queries like:
select Distance(
GeomFromText('Point(13.457 3)'),
geometry
) from table;
GeomFromText takes a string and outputs a geometry blob
Distance takes two geometry blobs and returns a double
In order to speed up the distance function I was wondering if I could
use aux_data to cache the parsed version of the first parameter since
this remains the same for every call. So far I haven't been able to get
this to work though, aux_data is always NULL, no matter what I try.
My hunch is that this is because the first parameter is the result of a
function call which could in theory return different values for each row
even if the input parameters are constant. Is that correct?
Are there any other ways to kind of memoize the GeomFromText function
(or the parameters to distance) besides aux_data?
Thanks,
Pepijn
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] recommended extension entry point name
On vr, 2013-08-30 at 09:09 -0400, Richard Hipp wrote: > On Thu, Aug 29, 2013 at 3:53 AM, Pepijn Van Eeckhoudt < > pep...@vaneeckhoudt.net> wrote: > Recently the extension loader was enhanced (I think for 3.7.17) so that it > tries the first naming schema first, then if that fails it tries > sqlite3_extension_init. So with newer versions SQLite either method > works. And the first method is certainly easier on the user. So for new development sqlite3_X_init is preferred over sqlite3_extension_init? Pepijn ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] recommended extension entry point name
http://www.sqlite.org/loadext.html states that: ...omitting the second argument for the load_extension() SQL interface - and the extension loader logic will attempt to figure out the entry point on its own. It will first try the generic extension name "sqlite3_extension_init". If that does not work, it constructs a entry point using the template "sqlite3_X_init" where the X is replaced by the lowercase equivalent of every ASCII character in the filename... The documentation for sqlite3LoadExtension on the other hand says: The entry point is zProc. zProc may be 0 in which case a default entry point name (sqlite3_extension_init) is used. Use of the default name is recommended. AFAICT the second description matches what the code actually does. The example extensions in ext/misc all use sqlite3__init. This avoids name clashes but makes it a little bit more cumbersome for people to load the extensions. What is the recommended practice for naming the extension entry point? Should I use sqlite3_extension_init or sqlite3__init? Thanks, Pepijn ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] recommended extension entry point name
http://www.sqlite.org/loadext.html states that: ...omitting the second argument for the load_extension() SQL interface - and the extension loader logic will attempt to figure out the entry point on its own. It will first try the generic extension name "sqlite3_extension_init". If that does not work, it constructs a entry point using the template "sqlite3_X_init" where the X is replaced by the lowercase equivalent of every ASCII character in the filename... The documentation for sqlite3LoadExtension on the other hand says: The entry point is zProc. zProc may be 0 in which case a default entry point name (sqlite3_extension_init) is used. Use of the default name is recommended. AFAICT the second description matches what the code actually does. The example extensions in ext/misc all use sqlite3__init. This avoids name clashes but makes it a little bit more cumbersome for people to load the extensions. What is the recommended practice for naming the extension entry point? Should I use sqlite3_extension_init or sqlite3__init? Thanks, Pepijn ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Android large file support patch
Yes, that's exactly what I'm doing. I wasn't sure if I should include those in the patch or not since they're machine generated. I can send the generated .S files in an additional patch if you like. Pepijn Op 1-jun.-2013 om 08:20 heeft Dan Kennedy het volgende geschreven: > On 05/31/2013 09:28 PM, Pepijn Van Eeckhoudt wrote: >> Sorry for the non-threaded reply. My subscription was set to digest mode... >> >> Patch is available at >> https://dl.dropboxusercontent.com/u/105584447/android_largefile.patch > Thanks for the patch. > > When I compile on Android with it, I get linker errors for ftruncate64(), > pread64() and pwrite64(). Various posts on the internet suggest that > one needs to compile the required wrapper functions into the app itself. > Is this what you are doing? > > Thanks, > Dan. > > > > >> >> Pepijn >> ___ >> sqlite-users mailing list >> sqlite-users@sqlite.org >> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > > ___ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] Android large file support patch
Sorry for the non-threaded reply. My subscription was set to digest mode... Patch is available at https://dl.dropboxusercontent.com/u/105584447/android_largefile.patch Pepijn ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] Android large file support patch
Hi all, I've ran into some issues running sqlite on Android when handling files larger than 4Gb. Support for this counts on glibc style large file support where off_t and off64_t are identical. In bionic (Android C runtime) this is not the case. off_t is always 32-bit; for 64-bit offsets off64_t and the corresponding 64 bit variants of functions must be used (ftruncate64, pread64, pwrite64, ...). The attached patch modifies os_unix.c to count less on off_t being a 64-bit value. Could someone review this and if approved integrate this upstream? Sincerely, Pepijn Van Eeckhoudt ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
