Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » ElevateDB Technical Support » Support Forums » ElevateDB General » View Thread |
Messages 1 to 9 of 9 total |
Client uses |
Thu, Mar 12 2009 11:54 AM | Permanent Link |
"James Relyea" | I'm rather new to ElevateDB, but this is what I'm seeing with the server as
plusses: It's a tiny install, has good performance, supports triggers, has built in security, can run with or without a UI, will run as a service, runs in multiple Windows OSes, and often consumes <20 megs of RAM and <15 megs of my swap file, and it's free to redistribute, and does not require any UNC access to the DBs. With all of those plusses, are there any reasons to use a client only solution? I'm using the server only, but I figured someone out here could give me some insight.why the server is not an optimal DB option and a client only is. Thanks jr |
Thu, Mar 12 2009 12:01 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | James,
<< With all of those plusses, are there any reasons to use a client only solution? I'm using the server only, but I figured someone out here could give me some insight.why the server is not an optimal DB option and a client only is. >> Most people creating single-user applications prefer to compile the engine into the application in order to keep distribution/installation issues to a minimum. But if you're happy with what you've got, there is absolutely no reason to change. -- Tim Young Elevate Software www.elevatesoft.com |
Thu, Mar 12 2009 9:55 PM | Permanent Link |
"Carlton Craighead" | Another concern is the problem your application is designed to address. If
its a single user application, an all-in-one approach is ideal. If its multiuser but local (like within a company), a networkable (local type) solution might be the choice. If its multiuser with individuals in different locations, possibly around the world, then the server approach is the ticket. I've worked on all three types of apps with Elevate. With the Client/Server version of ElevateDB, one has all the right tools in the box to cover every needed scenario (I'm assuming you are using Delphi). Or for .NET, the ElevateDB DAC provides the same solutions, but for the .NET world. What I have found useful is creating Delphi and .NET client applications and having both work against the same server -- very handy. And even though I'm dying to play with the Windows CE support Elevate has (been in mobile development for years), just been a bit too busy, but that's still another option. Elevate has managed to deliver a very useful set of tools. C "James Relyea" <JRelyea@JBRSoftware.com> wrote in message news:95AF91D2-6338-40DE-B11D-7A4DC48DEE7D@news.elevatesoft.com... > I'm rather new to ElevateDB, but this is what I'm seeing with the server > as plusses: > > It's a tiny install, has good performance, supports triggers, has built in > security, can run with or without a UI, will run as a service, runs in > multiple Windows OSes, and often consumes <20 megs of RAM and <15 megs of > my swap file, and it's free to redistribute, and does not require any UNC > access to the DBs. > > With all of those plusses, are there any reasons to use a client only > solution? I'm using the server only, but I figured someone out here could > give me some insight.why the server is not an optimal DB option and a > client only is. > > Thanks > > > jr > > > __________ Information from ESET NOD32 Antivirus, version of virus > signature database 3932 (20090312) __________ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com > > > __________ Information from ESET NOD32 Antivirus, version of virus signature database 3932 (20090312) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com |
Fri, Mar 13 2009 12:14 PM | Permanent Link |
Dale Derix | Hi James:
> With all of those plusses, are there any reasons to use a client only > solution? I'm using the server only, but I figured someone out here could > give me some insight.why the server is not an optimal DB option and a client > only is. I'm working on my first EDB project and have also wondered the same thing. It seems like a no brainer to me. Dale |
Sat, Mar 14 2009 5:41 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Dale
My take - if its a single user system why make them install two apps to do the work of one? Roy Lambert |
Thu, Mar 19 2009 2:02 PM | Permanent Link |
Dale Derix | Roy Lambert wrote:
> Dale > > > My take - if its a single user system why make them install two apps to do the work of one? > > Roy Lambert > Hi Roy: That's a good point. I haven't gotten that far in my development yet, but in a single user situation, in the startup code of the client, I am hoping to be able to detect if the server is running, and if not, start it up. (idea is to make it as transparent as possible for the user). Some of the issues I'm trying to address are: - Having two sets of code to maintain (f/s and c/s). - With customer support, having to support two types of installations. - Also, many of our customers eventually upgrade to a network version. If my app is already c/s, then its a piece of cake to accomodate this. Our previous app uses dbisam (f/s), and dealing with shared folders and permissions is probably one of the top tech support issues that we have do deal with (over and over again.......) On the other hand...... just writing this response to you has sparked some ideas. I'll have to revist the f/s idea. Maybe it's easier than I thought. Dale |
Thu, Mar 19 2009 2:33 PM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Dale
Remember two things 1) I'm a hobby programmer (over the years I think I'm made c£15k from it) and 2) I use f/s. From what I've read switching between f/s & c/s in DBISAM / ElevateDB is almost as simple as setting a property. There will probably some bits which will NEED different code but not many. Developing for c/s requires some effort to reduce data transport, especially for WANs, which means you do some things you wouldn't have to in f/s but they will work in f/s,its just that you're going to be shovelling a lot of data over the LAN that wouldn't with c/s so it might run a bit slower. Roy Lambert |
Thu, Mar 19 2009 2:56 PM | Permanent Link |
Dale Derix | > Remember two things 1) I'm a hobby programmer....
Wow! You cover quite a bit of ground for a hobby programmer. When do you find time for your day job? Dale |
Fri, Mar 20 2009 1:13 PM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Dale
Well - I'm in recruitment so at the moment I have some free time Roy Lambert |
This web page was last updated on Tuesday, May 7, 2024 at 06:25 PM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |