I'm sure that anything is possible, but I do not think that would be a practical approach. :)
What seems to "easiest" is relative - I find working directly with the SQLite codebase very, very easy. But I'm a C guy. The whole Tcl thing gives me the willies. So I wouldn't generalize things according to language anyway. -Tom > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > Sent: Thursday, December 21, 2006 12:56 PM > To: sqlite-users@sqlite.org > Subject: Re: [sqlite] Mathematical 'power' operator? > > Maybe a dumb queston, but: > As it looks it is easiest to work with SQLite from Tcl, is it possible > to code in Tcl and call that from VB/VBA? > > RBS > > > Well put. If Sqlite were turned into a junior Oracle, DB2 > or PostgreSQL > > then someone else would have to create a new Sqlite to handle the > > lightweight embedded RDBMS role! > > > > It is very simple to add functions to Sqlite, and since it > is a library > > you link into your application there is no reason not to > have your own > > Sqlite-local library which adds all the functions needed by your > > application. Many of the features people want to add to Sqlite are > > better added by the addition of a specifically targetted application > > layer. > > > > Those persons wanting the simplicity of Sqlite and all the > functionality > > of PostgrSQL might do better to re-assess their goals and > save time by > > using PostgreSQL and coming to terms the fact that the > extra complexity > > is the price to pay for the added functionality. > > > > In our applications we have done just that and have the advantage of > > simple SQL, excellent performance and small footprint in > our distributed > > applications. We use PostgreSQL where its enterprise features are > > necessary to handle large numbers of concurrent users. We > thereby avoid > > underkill and overkill. > > > > The add-on functions, and application interfaces are better being > > contributed software than to bloat Sqlite distributions and > be a boat > > anchor on its continued development. > > > > Tom Briggs wrote: > >> > >> > >> > >>>In the case of SQLite, I (arguably) have to use a 3rd party > >>>management > >>>tool, for which my custom functions are no longer available. I'm > >>>curious how others handle this. > >>> > >>>A. You don't need or use any custom SQL functionality > >>>B. You don't use a 3rd party SQLite management tool > >>>C. Something else I haven't thought of? > >> > >> > >> I think that the key point you're missing here is that > SQLite is not > >> intended to be standalone database system like the other > products you > >> mentioned (Access, Oracle, etc.) - it is an embeddable > database library. > >> It happens to have a convenient command line interface > that allows it to > >> be used as a standalone database, but that's just a shell > (pun intended) > >> that allows you to get to the library itself. The 3rd party "front > >> ends" to which you refer are really application consumers of SQLite > >> itself - not add-ons to or features of SQLite. In other > words: it's a > >> development tool, not a database. > >> > >> Now, as for a "power" function: we had exactly the same > need when we > >> first started using SQLite. Our solution: we added it. > The source code > >> is freely available, after all. Adding a new function to > the code is > >> shockingly straightforward; from there you simply compile > your version > >> of the library and use that in your application(s). > Quick, simple and > >> portable, both across platforms and applications using > your version of > >> the library. > >> > >> -Tom > >> > >> > >> > >> > >> > -------------------------------------------------------------- > --------------- > >> To unsubscribe, send email to [EMAIL PROTECTED] > >> > -------------------------------------------------------------- > --------------- > >> > > > > > > > -------------------------------------------------------------- > --------------- > > To unsubscribe, send email to [EMAIL PROTECTED] > > > -------------------------------------------------------------- > --------------- > > > > > > > > > > > -------------------------------------------------------------- > --------------- > To unsubscribe, send email to [EMAIL PROTECTED] > -------------------------------------------------------------- > --------------- > > ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
