Welcome to the SQLitening support forums!
Started by ressystems, January 08, 2011, 01:15:56 am
Quote1. Can we compile the SQLightening Client in another Basic that supports Windows CE? Maybe Real Basic or GLBasic?
Quote2. If we cannot do , can we build our own SQLitening? Seems to be about 640 lines of code in that file ... is it something we can re-code in Windows w/ C++ or C# to run on the Windows CE platform?
Quote3. For the Zlib, is it using a standard compression / decompression, or is this proprietary?
QuoteRegarding re-writing the Client DLL to be in VB or C# ... what all would need rewritten? Just the SQLiteningClient.Bas file?
Quote from: Fred Meier on January 08, 2011, 03:24:25 pmQuote1. Can we compile the SQLightening Client in another Basic that supports Windows CE? Maybe Real Basic or GLBasic?Yes, but many of the special abilities (such as TCP/IP processing) are built-into PB as Basic extensions (my term). These extensions would have to be considered/converted for another Basic.
Quote from: Fred Meier on January 08, 2011, 03:24:25 pmQuote2. If we cannot do , can we build our own SQLitening? Seems to be about 640 lines of code in that file ... is it something we can re-code in Windows w/ C++ or C# to run on the Windows CE platform?Yes. The 640 lines are only SQLiteningClient.Bas, you would also have to re-build SQLitening.Bas. SQLitening.Bas allows for both local and remote mode. If you wanted to develope a remote mode only version then SQLitening.Bas and SQLiteningClient.Bas should be combined.
Quote from: Fred Meier on January 08, 2011, 03:24:25 pmI would be glad to help in any way. The NSBasic solution seems possible (only from reading their web site).
Local lsA as String slConnect slRunProc "BEntry2", 0, 0, lsA, ""
Quote Procs will allow you to write your own code which will run at the server accessing SQLite in local mode. These Procs can talk directly to SQLite or can go thru SQLitening. Not using SQLitening could result in a slightly more efficient Proc but is harder to develop. Procs will also work fine at the client in local mode. This concept is similar to database procedures in Oracle and MySQL except here you get to code in Basic (or any language than can produce a standard DLL) rather that their proprietary language. Using Procs can greatly improve response time by reducing messages to/from the server. You must developing a Proc very carefully because it runs as part of the service on the server. If your Proc crashes your service will also crash. Your Proc must do proper clean-up. You must close all open connections, databases, and sets before ending/unloading. CAUTION1: This DLL is running as part of the service on the server so all sets must be closed/finalized ASAP so locks are released. (don't return to the caller with open/un-finalized sets) CAUTION2: This DLL must be thread safe so careful with globals or use Threaded global variables. All Procs that are to be called with slRunProc must be named SQLiteningProc?.Dll where ? must be a single alpha suffix character of A thru Z. Each Proc can have as many entries as required and may be named whatever you would like. The suffix and entry name are used in slRunProc. Each entry must receive the following parms and returns a Long: byval rhDab as Dword, _ byval rlTcpFileNumber as Long, _ blParm1 as Long, _ blParm2 as Long, _ bsParm3 as String, _ bsParm4 as String)Export as Long If the Proc is called by using the load_extension SQLite function then the only parm is Dab and returs a Long: byval rhDab as Dword If a database is open when the Proc is called then Dab will contain the handle and it can be used to do SQLite calls directly or can be passed to slOpen so that the previously openned database can inherited by SQLitening.Dll. If Dab is zero then the database must be opened here and then closed before returning. If running remote then TcpFileNumber will contain the unique number assigned by the server to this connection or zero if running local. Note that the two longs and two strings parms are both received and passed (in and out). These are the four parms you will use to communicate with the Proc using slRunProc. The return value from this function must be zero if all OK or non zero if an error occurs. ==========>>> About this sample Proc This Proc contains the follow two sample entries: Entry 1 ===>>> Will inherit the database handle from the caller. Returns selected data from Parts table and from an attached database named T. This entry calls SQLitening for all processing. Entry 2 ===>>> This example opens it's database rather than inheriting and also attaches a database and names it T. Returns selected data from Parts table and from the attached database named T. This entry calls SQLitening for all processing. Note that the slClose is REQUIRED!!!
Quotewhat communication server are you currently using to communicate w/ the SQLitening Server?
Quotethat sounds like good approach for a NSBasic solution. A couple of subs or functions in NSBasic should be able to handle that. No need to rewrite a client.dll for CE. I am going to have a look at that.