Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » ElevateDB Technical Support » Support Forums » ElevateDB General » View Thread |
Messages 1 to 3 of 3 total |
Server procedures and ElevateDB |
Tue, Jul 10 2007 8:27 PM | Permanent Link |
Oliver Bock | 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 |
Wed, Jul 11 2007 8:03 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | 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 |
Wed, Jul 11 2007 8:48 PM | Permanent Link |
Oliver Bock | 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 |
This web page was last updated on Tuesday, April 30, 2024 at 03:55 PM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |