Re: [sqlite] Fortran 95 Language Bindings
As you suspect, it is straightforward to make a Fortran to SQLite binding. Here's an example with Fortran 77: http://danial.org/sqlite/fortran/ I don't see why an F95 binding would need to be compiler specific. -- Al On 4/14/07, Gary Scott <[EMAIL PROTECTED]> wrote: Hi, this is my first post, so please excuse any etiquette goofs. I'm researching incorporation of SQLite into a project. It would appear relatively straightforward to develop an F95 language binding, however it is likely to be compiler specific (extensions required to adapt calling syntax to C). Is this a suitable place to ask basic C-oriented questions relative to the existing API? Also, it would be my desire to not only map the existing API exactly (as public), but to also create a small additional layer atop the existing API with a slightly higher abstraction level to hide some of the low levelness of the API (pointers, handle passing, etc.). Would anybody be interested in helping or critiquing as I progress? (I haven't decided to do this yet, I'm awaiting corporate approval to use public domain software in my project, which they have refused in the past. This part of the project would be on my own time so as to not involve company ownership issues). -- Gary Scott mailto:[EMAIL PROTECTED] dot net Fortran Library: http://www.fortranlib.com Support the Original G95 Project: http://www.g95.org -OR- Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html If you want to do the impossible, don't hire an expert because he knows it can't be done. -- Henry Ford - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] Supporting databases larger than 2GB on FAT filesystems?
Alright thanks! I will look into that. /Ludvig On 4/14/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: "Ludvig Strigeus" <[EMAIL PROTECTED]> wrote: > Does Sqlite support databases larger than 2GB on FAT filesystems? SQLite supports large databases just fine. It is FAT that does not support large files. > > If not, how hard would it be to add so it uses additional files for the > pages that don't fit in the first file? > The OS interface in SQLite is modular and interchangable. If you compile with -DSQLITE_ENABLE_REDEF_IO=1, you can even interchange the OS interface layer at runtime. I suggest you write a new OS interface layer specifically for FAT that allows the SQLite core to open, read, and write a single file, but which splits the reads and writes across multiple files where each of the multiple files is less than 2GB. -- D. Richard Hipp <[EMAIL PROTECTED]> - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] Re: SQLite and nested transactions
I followed every one of these threads and it is really good stuff.
I've done some research to realize I need to do more.
I see that most of you are in the client/server world where you can ask
the client various questions about the query.
In my case, I am a standalone server embedded in a device that has
communication in one direction only. Application to device.
The device can only return status but the device can only return status
when the application asks for it.
The device must support nested transactions.
I gave the following example:
BEGIN parent;
insert into t values ('a');
BEGIN child;
insert into t values ('b');
insert into t values ('c');
insert into t values ('d');
ROLLBACK child;
insert into t values ('e');
COMMIT parent;
Someone asked why I just didn't do the following:
BEGIN parent;
insert into t values ('a');
insert into t values ('e');
COMMIT parent;
The reason for this is that the rollback was caused by a system error
and not a program decision.
For example:
My device may have enough disk space to store records 'b' and 'c' but
not 'd'. So this transaction must be rolled back.
Also, since I have enough space to store 'b' and 'c' I definitely have
enough space to store 'e' since 'b' and 'c' were rolled back.
This is a requirement for my device and may not be a real world
situation for any other system.
Ray
-
To unsubscribe, send email to [EMAIL PROTECTED]
-
[sqlite] Fortran 95 Language Bindings
Hi, this is my first post, so please excuse any etiquette goofs. I'm researching incorporation of SQLite into a project. It would appear relatively straightforward to develop an F95 language binding, however it is likely to be compiler specific (extensions required to adapt calling syntax to C). Is this a suitable place to ask basic C-oriented questions relative to the existing API? Also, it would be my desire to not only map the existing API exactly (as public), but to also create a small additional layer atop the existing API with a slightly higher abstraction level to hide some of the low levelness of the API (pointers, handle passing, etc.). Would anybody be interested in helping or critiquing as I progress? (I haven't decided to do this yet, I'm awaiting corporate approval to use public domain software in my project, which they have refused in the past. This part of the project would be on my own time so as to not involve company ownership issues). -- Gary Scott mailto:[EMAIL PROTECTED] dot net Fortran Library: http://www.fortranlib.com Support the Original G95 Project: http://www.g95.org -OR- Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html If you want to do the impossible, don't hire an expert because he knows it can't be done. -- Henry Ford - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] Supporting databases larger than 2GB on FAT filesystems?
"Ludvig Strigeus" <[EMAIL PROTECTED]> wrote: > Does Sqlite support databases larger than 2GB on FAT filesystems? SQLite supports large databases just fine. It is FAT that does not support large files. > > If not, how hard would it be to add so it uses additional files for the > pages that don't fit in the first file? > The OS interface in SQLite is modular and interchangable. If you compile with -DSQLITE_ENABLE_REDEF_IO=1, you can even interchange the OS interface layer at runtime. I suggest you write a new OS interface layer specifically for FAT that allows the SQLite core to open, read, and write a single file, but which splits the reads and writes across multiple files where each of the multiple files is less than 2GB. -- D. Richard Hipp <[EMAIL PROTECTED]> - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] Need help understanding SQLITE_ERROR[1] problem
"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > In the following pseudo-code which works the first time through either > Function A or Function B I get a problem when either function is > executed a second time. > > I get the following error: > > SQLITE_ERROR[1] - cannot start a transaction within a transaction > This means that you tried to run BEGIN twice in a row without an intervening COMMIT or ROLLBACK. -- D. Richard Hipp <[EMAIL PROTECTED]> - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] sqlite3_rowid
Marco Bambini <[EMAIL PROTECTED]> wrote: > I need a way to automatically have the rowid for all queries issued > by our users (without modifying the original sql queries). > A lot of time for some queries (COUNT(*) for example), it is simply > not possible to obtain a valid rowid, so it could just be set to -1. > > Is this a planned feature? If no and if I would like to try to add it > myself, do you an advice for me about what is the best way to proceed? > A possible API could be: > long long int sqlite3_rowid(sqlite3_stmt*); This is not a planned feature. Adding this would slow down the code for vast majority of people who do not need it. Note also that the interface you propose is inadequate because in a join, different elements of the result set come from different tables and thus have different rowids. -- D. Richard Hipp <[EMAIL PROTECTED]> - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] DELETE row problem
"dszhang" <[EMAIL PROTECTED]> wrote: > when i delete some row in my table ... i find the sqlite will free > some memory that have been free[d] previous[ly]. > my question is why that thing happen and how to solve it? > SQLite should never call free() on the same piece of memory twice. If it does, that is a bug. Please report the specific version number of SQLite that you are using and what SQL statements you invoke to get it to occur. But we test very carefully for this sort of thing and no such errors have appeared in a production release in a long time. I suspect that the error is in your application code, not in SQLite. -- D. Richard Hipp <[EMAIL PROTECTED]> - To unsubscribe, send email to [EMAIL PROTECTED] -
[sqlite] Announcement: mod_auth_sqlite3
For all of you who have been wanting to use SQLite3 to manage authentication on your Apache web servers, I have just released mod_auth_sqlite3. You may download it from http://www.lazarusid.com/download/modauthsqlite3-1.0.tar.gz The module includes both a command line and a web utility for managing the password database. There will be enhacements to the web interface over the next month or so, but it is sufficient to manage users currently. Clay -- CeaMuS http://www.ceamus.com Simple Content Management - To unsubscribe, send email to [EMAIL PROTECTED] -
[sqlite] Rollback journal bitmap size
I read this on Sqlite's webpage (http://www.sqlite.org/whentouse.html): When you start a transaction in SQLite (which happens automatically before any write operation that is not within an explicit BEGIN...COMMIT) the engine has to allocate a bitmap of dirty pages in the disk file to help it manage its rollback journal. SQLite needs 256 bytes of RAM for every 1MB of database. For smaller databases, the amount of memory required is not a problem, but when database begin to grow into the multi-gigabyte range, the size of the bitmap can get quite large. If you need to store and modify more than a few dozen GB of data, you should consider using a different database engine. If I change the page size to a higher value, such as 8192, I suppose the bitmap size goes down as well.. so maybe the website text should be changed to reflect this? /Ludvig
