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

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

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

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

Dale


My take - if its a single user system why make them install two apps to do the work of one?

Roy Lambert

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

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

> 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

Dale


Well - I'm in recruitment so at the moment I have some free time

Roy Lambert