Re: [sqlite] SQLite as a Delphi unit (was: SQLite Options)

[Stephen Chrzanowski]

@Clemmins;

I'll read over that a bit more carefully, and see if there are any hints on
HOW-TO in there.  I'm using the free version of Berlin ATM, and when I win
a small lottery, I'd love to upgrade as I REALLllly miss the code reformat
functionality of previous versions.  (Previous employer gave me, directly,
a license for D5 and 7 -- Can't tell ya in how many places I've got those
codes stored. ;) )

@Ryan;

As a developer, who's only done code always for for myself, previous
employer for in-shop work only, and a few friends, I'm in both camps for
"Use DLLs" and "Single EXEs".  I agree with both sides of the argument,
but, my mind pertaining to the distribution of SQLite3 DLLs by 3rd parties
leans me towards the Single EXE methodology, at least for my applications.
Even my personal rig has been (temporarily) messed up due to a 3rd party
app that decided its version of the SQLite library is more important than
what existed before.  Knowing that capability exists for 3rd parties to
steam roll a working machine into a partially working machine, this event
has affected how I build and stage things in a couple of ways, but that's
another story.

When performing upgrades to my software, and distributing it, typically, my
EXE code is being updated as well anyways.  If the DLL has to be updated as
well, well, then, that's great, and that DLL would be part of the
distribution anyways.  I understand that for MASSIVE application packages,
where many EXEs rely on single DLLs, yeah, then DLL methodology is probably
the way to go, as a small 50k file to fix a problem for many applications
in the package, makes perfect sense.  However, working with already a
single do-everything-it-needs-to-do-under-one-roof kind of application, I'm
able to see the advantages on BOTH sides of the fence.  Due to the unknown
recipient machines, in regards to availability of SQLite3 being present at
all, the correct version that supports my code, and other varying details
that I'm overlooking about an unknown entity, having what I know works in
one single source, and it dealing with everything internally makes more
sense to me.  Sometimes, I even build in the JPGs for icons, mouse cursors,
sounds, and all that DIRECTLY into the EXE, as I don't want people to
change a mouse click into a train horn or whatever.  (As fun as that is ;) )

Don't get me wrong.  Merritt to BOTH sides of the coin.  Right now, I just
don't have the option of a truly single EXE with baked in DB engine
capabilities, and I know that I miss it.  If I can figure out the OBJ
methodology, and get the wrapper I use (
http://www.itwriting.com/blog/articles/a-simple-delphi-wrapper-for-sqlite-3)
to work with the OBJ or DLL based on build conditions, I'm all for it.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite as a Delphi unit (was: SQLite Options)

[R Smith]

On 2017/02/17 5:17 PM, Stephen Chrzanowski wrote:

(A little bit off topic)

On Fri, Feb 17, 2017 at 9:32 AM, R Smith  wrote:


. though some wrappers exist for almost all programming languages and
they are relatively easy to use too - *but for brute speed and control,
use the API directly.*


Ever since I found SQLite3 and a decent wrapper that does exactly what I've
needed it to do, I've ALWAYS wanted to do a direct port of the Amalgamation
into a Delphi/Pascal unit so I can just include it and have the
functionality built in, period, built by the Pascal engine.  However, when
I last looked at the Amalgamation source code, it was 4 meg in size.  It'd
take me a while :]

One of these days.


You don't need a Port, just a good translation.  A port won't be 
update-able, an API translation would be. Best of this is to link a DLL 
which means the C code is all compiled in the DLL and Delphi merely maps 
the DLL using C calling conventions, easy mode - not to mention the boon 
of being able to swap out DLLs easily without recompiling the parent exe.


Prefer not to link? Delphi can compile C files directly into .obj files 
which you can link against at compile time (so no external libraries), 
but then you lose the option of swapping out newer DLLs and you need to 
re-compile against the newest C files. The Delphi system might be 
expensive, but the compilers are free (at least some versions of it).


Another option is a good Delphi wrapper that makes a database connection 
into an object you can use as needed, but without the fat.


Others and myself have, over the years, created very good versions of 
these for Delphi - you can see them in action in many products, most 
notably perhaps SQLitespeed (http://www.rifin.co.za/software/sqlc/), and 
you are welcome to have the code - they are free and up to date, 
supporting all versions (but only tested up to XE8). Poke me off-list if 
you would like them.


What you definitely don't want to do is Porting the code to a delphi 
language (C++, Obj Pascal etc). That will require re-inventing the wheel 
(or at least re-manufacturing it a bit) with every release.


Cheers,
Ryan



___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite as a Delphi unit (was: SQLite Options)

[Clemens Ladisch]

Stephen Chrzanowski wrote:
> Ever since I found SQLite3 and a decent wrapper that does exactly what I've
> needed it to do, I've ALWAYS wanted to do a direct port of the Amalgamation
> into a Delphi/Pascal unit so I can just include it and have the
> functionality built in, period, built by the Pascal engine.  However, when
> I last looked at the Amalgamation source code, it was 4 meg in size.  It'd
> take me a while :]

Delphi can directly link to .obj files created by the Borland C compiler.
(And BCC 5.5.1 is free.)  See this thread:
http://sqlite.1065341.n5.nabble.com/latest-sqlite-3-with-Delphi-5-professional-td73388.html


Regards,
Clemens
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users