Hi,

I have a problem with the SQLite library (www.sqlite.org). I believe Michael helped me with the conversion of the headers and the unit that Eric Jourde wrote.

This all works fine, however when compiling a program with the debug options (-g, -gg etc), it won't produce any tracebacks of error. It makes it impossible to trace down something like:

An unhandled exception occurred at 0x0809911D :
List index exceeds bounds
(1)
0x0809911D

Without the source and line numbers ? (I think perhaps the SQLite library is interferring with the debug symbols in the program? I'm not sure).

Any ideas ?

cheers
James

You mean that inside GDB you got information
about the source position and the C structures used...

However I would still like to know why the backtrace wasn't there to begin with... Normally it is :)

The problem is that GDB is reading the dynamic library to get this information, which is not
the case for the -gl option, only the main executable debug info is read.

If you link statically to the SQLite library,
you might still not get the correct source position inside the library, because Free Pascal only generates stabs debugging infos, while GCC usually uses dwarf-2 debugging format.
In that case, recompiling the library with
adding -gstabs+ to the CFLAGS option might help.

I found a solution to this problem by using a break point on the address in gdb (didn't know this till I did some digging on the break command).

However I would still like to know why the backtrace wasn't there to begin with... Normally it is :)

cheers
James

Eric will have written that unit for BeOS, so I would ask if anyone tested it for other platforms.... Had a look on BeShare and he's not online, but that is certainly a question that needs to be addressed first.

Matt

0x0809911D

Matt Emson wrote

Eric will have written that unit for BeOS, so I would ask if anyone tested it for other platforms.... Had a look on BeShare and he's not online, but that is certainly a question that needs to be addressed first.

I know he wrote it. I regularly speak to him on MSN. There was a problem with using it, for some reason he didn't need to use the cMem unit back when he wrote the unit. But he had used a very old version of sqlite at the time. I guess the SQLite library has changed dramatically since 2.7...

I have tested it on Linux, and the only modification to the unit necessary (I think) is that you have to use the cMem unit.

It works quite well and I'll continue to use this for my programs that require an embedded database vs. mysql server.

cheers
James

I think that was more to do with whoever ported SQLLite to BeOS rather than him actually wanting to use an older version ;-)

Matt

How so ? It's been fixed there was no problem with his unit other than the fact that, with the current version of SQLite the cMem unit was needed in order because of the way SQLite uses memory.

cheers
James

How so ?

James, he did *not* port this app to BeOS, some one else did. He wrote a Pascal interface to the version that that developer had ported to BeOS (you're following me right ;-). He therefore had no option but to use the version ported under BeOS, unless he ported a newer version himself, right? So therefore, he was only able to do the interface as per the version available to him. Therefore my comment. Do you understand? No trickery involved.

Looking at the BeBits page, (http://www.bebits.com/app/3156), 2.7.1 was the last port made (circa November 2002).

It's been fixed there was no problem with his unit other than the fact that, with the current version of SQLite the cMem unit was needed in order because of the way SQLite uses memory.

Cool. Let him know ;-)

Actually, got it to compile and run under Delphi with only about 2 or 3 changes.

Change all ref's to 'strings' to 'sysutils', and there is an assignment to 'OnData' that must read:

OnData := SQLOnData;

rather than

OnData := @SQLOnData;

Other than that it compiles and runs.

One question, why is StrAlloc in Strings??? It should be in Sysutils for Delphi compatibility. I thought the main FPC thrust was now for Delphi compatibility over Turbo Pascal?!?!

Matt

Now I'm following you. Yes I'm aware that Eric did not actually develop this unit, one of his (people) did. His/Her/It's name is unknown to me. ;)

It should be released in future versions of the FCL according to Michael of FPC :) I can send you a tar.gz of the header translation and the unit though...

cheers
James

Good question. However I don't really care about Delphi compatibility, as as such I think the FPC developers put it in Strings for a very logical reason. Afterall it is a String function call.

cheers
James

Um... well, AFAIK Eric did write the PASCAL unit, but some other person ported the C code that makes up the SQLite library to BeOS. The two acts are quite seperate.

Anyway....

Strings.pas is legacy, from TurboPascal days, where as the modern 'SysUtils' is a unit that contains almost all of the utility functions that exist. I'd much rather use a single unit and let the compiler strip the unwanted symbols rather than have to include 5+ units to cover String, integer, variant etc functionality. Maybe that's just me though <g>

Matt

Hi all !

Under BeOS, the port is really easy : sqlite compile nearly out of the box from official sqlite sources. I have succesfully compiled sqlite 2.8.3 two or three weeks ago (during the last thread about sqlite in this list). Only one change was needed. I had only change sqliteOsSleep's implementation to use snooze instead of usleep, not available in Be's headers.

In fact, Eric's version is a quick port of TSQLIte component (available at http://www.torry.net/db_directsql.htm) from Delphi and Windows to FPC and BeOS (mainly removing Windows only functions and dynamic loading). That is why his unit works under Linux. Maybe Delphi users and FPC users under Windows should use TSQLite component directly.

Now, there is also a DBExpress driver available for Delphi users (and maybe kylix's one with some work ?).

Under BeOS, this unit is not necessary as far as i know (but not well tested, only trivials samples). If someone have some code that show this problem (and the improved wrapper), i can test them under BeOS.

Bye

Olivier