• Welcome, Guest. Please login.
 
July 07, 2020, 03:13:42 am

News:

Welcome to the SQLitening support forums!


Windows CE

Started by ressystems, January 08, 2011, 01:15:56 am

Previous topic - Next topic

ressystems

Seems we've got a bit of a problem.

We have a Windows CE v6 on an ARM processor that we need to have connect to a remote SQLite database.  I was really hoping to use SQLitening, but it's not running very well on the Windows CE box.  I spoke w/ Power Basic today, and that's not likely to ever happen.

What other options do we have?

1.  Can we compile the SQLightening Client in another Basic that supports Windows CE?  Maybe Real Basic or GLBasic?

2.  If we cannot do [1], 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?

3.  For the Zlib, is it using a standard compression / decompression, or is this proprietary?


--
Anthony

Rolf Brandt

I have been thinking on the same lines since I use mobile clients extensively in my projects. Rewriting the SQLitening Client in VB or C# I think would be the only solution.

At present I use a communication server that connects the mobile clients to the SQLitening Server. That works ok since I use a limited and fixed set of instructions. But talking directly to SQLitening from a mobile would be great.
I like to cook with wine - sometimes I even add it to the food.
www.rbsoft.eu

ressystems

Rolf,

Do you mind sharing ... what communication server are you currently using to communicate w/ the SQLitening Server?

I got an email from George @ NSBasic that we might be able to build a SQLitening Client DLL for the Windows CE device.  I'm not sure how that would work.

Regarding re-writing the Client DLL to be in VB or C# ... what all would need rewritten?  Just the SQLiteningClient.Bas file? 

--
Anthony

Fred Meier

Quote1.  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. 

Quote2.  If we cannot do [1], 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. 

Quote3.  For the Zlib, is it using a standard compression / decompression, or is this proprietary?

It is standard and anybody can use ZLib. see http://www.zlib.net/zlib_license.html

QuoteRegarding re-writing the Client DLL to be in VB or C# ... what all would need rewritten?  Just the SQLiteningClient.Bas file?

Same as #2 above.

I would be glad to help in any way. The NSBasic solution seems possible (only from reading their web site).

ressystems

Quote from: Fred Meier on January 08, 2011, 03:24:25 pm
Quote1.  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. 


I've re-checked with George at NS Basic - who's been great help over the weekend.  While we could (possibly) compile an NS Basic app which used SQLitening, it would need to be part of the app.  IE, we cannot compile a Windows CE DLL with NS Basic.  We'll need to recode the client in C# or VB.NET, and target the Windows CE platform.

Quote from: Fred Meier on January 08, 2011, 03:24:25 pm
Quote2.  If we cannot do [1], 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. 


Yes, I think (for our purposes) we just need a remote only mode.

Quote from: Fred Meier on January 08, 2011, 03:24:25 pm
I would be glad to help in any way. The NSBasic solution seems possible (only from reading their web site).


Unfortunately NSBasic isn't going to be possible.

Fred, is there any way you could point out the functionality that we'd need to replicate for remote mode only?  Specifically the functions in the two source code files?  Ignoring the TCP methods, etc..

I think the basic specs probably would need to:

- Connect to a SQLitening server and database
- Execute select, insert, update, and delete statements with support for all datetypes (int, long, string, blob, etc...)
- Disconnect

I'm not that worried about copying / backups / etc... for a first release.  IE, I suppose we'll need to replicate the protocol to do the above.  Is that documented anywhere (other than the source code?)

--
Anthony

Fred Meier

You can do everthing by converting only two or three of the functions in
SQLitening.Bas and SQLiteningClient.Bas.  They are:
   1. slConnect
   2. slRunProc
   3. slDisconnect (optional, happens automatically when TCP connection is dropped)

Using this technique you would make-up your own commands using the parms
of RunProc.  This would result in the fastest possible response time cause
all SQLite is done in local mode on the server and message size and
quantity is the smallest.  As the doc states, the procs can be written in
any language that produces a standard DLL. 

Check out Entry2 from SQLiteningServerProcB.Bas.  Of course you can have
the four parms mean anything you want.  Here is how it would be called:

   Local lsA as String
   slConnect
   slRunProc "BEntry2", 0, 0, lsA, ""



The doc from SQLiteningServerProcB.Bas:
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!!!


You are restricted to 26 different procs (A-Z suffix) but each proc can
have an unlimited number of entry points.  The only other restriction is
you imagination!   :)

Rolf Brandt

Quote
Hello Fred,

that 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.

Right now I started to convert my mobile client software to XP/Win7 based devices. That is very simple since I can just use the SQLitening client as is. But I still have a lot of customer that use WindowsMobile Phones, so this might be a good way.


Anthony,

Quotewhat communication server are you currently using to communicate w/ the SQLitening Server?


This is a simple TCP/IP server written in VB6, something like a chat server. The mobile client just send simple status messages to the server, usually GPS coordinates, status of vehicle, short text messages, etc. The server then communicates with the SQLitening server. Like this I use only 7 to 8 MB of data a month per vehicle. This was important in the early days of mobile internet connections when the German Telekom sold data plans with 5 or 10 Mb volume per month.

Rolf

I like to cook with wine - sometimes I even add it to the food.
www.rbsoft.eu

ressystems

Fred,

Interesting.  So, one possibility is to write the client in C# or VB.

Another possibility would be to implement:

- slConnect
- slRunProc
- slDisconnect

... and also write a DLL which runs on the server side, and implements the procedures (which can be written in any language)?  Is that correct?  Or does the client-side DLL need to be written in Power Basic?


--
Anthony

Fred Meier

Option 1.  Write a "full" client DLL in C# or VB.  Write nothing on server.

Option 2.  Wirte a Connect and RunProc client DLL in C# or VB.  Write Proc DLL's on server in any language.

Option 3. Write a couple of subs/function in NSBasic on client. Write Proc DLL's on server in any language.

Rolf liked option 3.
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.


ressystems

Fred,

Thanks.  However, it would appear that if you want to write an app for Windows CE using NSBasic, you must write the entire application in NSBasic, which we cannot really do.

We'll end up doing Option 1 or Option 3, I'll let you know how it goes.

Also, just so you are aware, we have had a group write for us an NHibernate wrapper for SQLitening, which uses the SQLite libraries.  It's actually very slick, though it's missing Blob support.  IE, inside of NHibernate, .NET developers can decide to use either SQLite (local mode), or SQLitening (remote mode), without making any code changes.

I'm happy to Open Source the code, just not quite sure where to put it.

(I wanted to use our NHibernate code on the Windows CE device as well, but as it turns out, that's not possible.)


--
Anthony