I am investigating converting my DBISAM client/server application to
ElevateDB.  My application uses DBISAM's Server Procedures as
middleware: my server procedures include a lot of Pascal and a lot of
SQL.  I use a single .exe for both the client (GUI) and the server
(WinNT service).  (Command line arguments and registry settings tell it
what mode to start in.)  To be clear: I do not use dbsrvr.exe because I
have written my own server service.

It appears that this architecure will not work with ElevateDB because
Delphi stored procedures must be implemented in a DLL.  Therefore I must
create a new .dll, which will be mostly common with the .exe.  The
disadvantages for me are:

- In order to execute SQL, my Delphi stored procedures must create
  separate client/server sessions to dbsrvr.exe.

- My setup.exe will become bigger.
  (My modules are very interlinked.  It would be hard
  to separate the bits only required on the server from the
  bits needed for the GUI.  Particularly as the .exe can also run
  in DBISAM standalone mode (for single users), using both the client
  code and the server code at the same time.)

- I will need to keep two Delphi project files up to date.

- When debugging I will need to switch projects and copy both the
  .dll and the .exe around.  There will be more opportunities
  for the versions to get out of sync.

- The DLL must reside with the server configuration file, which must be
  user-writeable and therefore cannot be in C:\Program Files with the
  rest of my software. (Is this right?)

There have been hints on this newsgroup that ElevateSoft may re-enable
something akin to the old server procedures.  Obviously I will wait for
this if I can.  Tim: are you able to clarify your plan/schedule?

Can anyone else comment on my situation?  How have others who used to
use Server Procedures got around it?

Regards,
  Oliver

Oliver,

<< - In order to execute SQL, my Delphi stored procedures must create
separate client/server sessions to dbsrvr.exe. >>

One of the reasons that this is done this way is to encourage you to move
any code that uses database operations into straight SQL/PSM code and only
have code in the external stored procedures that absolutely positively needs
to be there because it requires more low-level coding or external access to
devices.

<< - The DLL must reside with the server configuration file, which must be
user-writeable and therefore cannot be in C:\Program Files with the rest of
my software. (Is this right?) >>

Yes, but usually in such a situation I would recommend that you simply keep
a copy of the DLL(s) in the installation directory, and copy them to the
configuration path as necessary.

<< There have been hints on this newsgroup that ElevateSoft may re-enable
something akin to the old server procedures.  Obviously I will wait for this
if I can.  Tim: are you able to clarify your plan/schedule? >>

It's on our list of improvements, but not particularly very high on the list
at this point due to other more pressing improvements being required.  I'll
see what I can do for you in the upcoming 1.05 release, but I can't make any
promises.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim Young [Elevate Software] wrote:
> << - In order to execute SQL, my Delphi stored procedures must create
> separate client/server sessions to dbsrvr.exe. >>
>
> One of the reasons that this is done this way is to encourage you to move
> any code that uses database operations into straight SQL/PSM code and only
> have code in the external stored procedures that absolutely positively needs
> to be there because it requires more low-level coding or external access to
> devices.

There is certainly more I can do with cursors than we could do with
plain SQL in DBISAM.  Unfortunately I still have a bunch of things that
cannot be translated because I use DBISAM as middleware to handle other
aspects of my application.  (e.g. I allocate sequential invoice numbers
when a new invoice form is opened and then save or release them
depending on whether OK or Cancel is clicked.)

DBISAM has been fantastic in this way, allowing me to produce a
sophisticated client-server application without needing to integrate
another vendor's middleware.  (Extra complexity, extra dependencies,
extra bugs, more complicated TCP/IP setup.)

> << There have been hints on this newsgroup that ElevateSoft may re-enable
> something akin to the old server procedures.  Obviously I will wait for this
> if I can.  Tim: are you able to clarify your plan/schedule? >>
>
> It's on our list of improvements, but not particularly very high on the list
> at this point due to other more pressing improvements being required.  I'll
> see what I can do for you in the upcoming 1.05 release, but I can't make any
> promises.

Anything you can do would be fantastic.  Thanks!


Regards,
  Oliver