Hello All:

As a very new user of ElevateDB, and a newbie to Client/Server, I would love to see some
threads in here regarding various "Best Practices" on designing and deploying ElevateDB
applications.  The ElevateDB manual covers a lot of ground on "what" things are.... but
does not say much on "how" they should be used.  (unless I'm looking in the wrong spot).
Unless you already have the whole Client/Server/SQL thing down, its hard to know where to
start.... and also what a good design looks like.

Maybe some of you veterans can get some discussions going and share your thoughts and
approaches to various issues:

For starters, here are a couple of topics that I would be interested to know more about:

1.  What issues are important when designing for remote access (ie: internet), and how to
address them?  

2. What are the pitfalls in using TEDBTables in a C/S app.?  Or are there any?  (I know
this is a really basic question... but having no experience in the word of servers, I have
no idea).

3.  How to set up a key field so that a unique key is generated when a new record is
posted.  With DBISAM, I would just create a key in the OnBeforePost event is stuff it in
the field.  But I suspect there are better ways to do this with ElevateDB, what are they,
and how to do it?  

4.  What are the best practices when deploying your ElevateDB server app on a Vista
machine, or how about Windows 2003 server.  What goes where, and what permissions should
be set.

5.  Same thing when deploying the client app?

I would encourage you to create a separate thread for each topic.... and be specific in
your responses as many of us just starting out don't have the benefit of your accumulated
experience.

My hope is that some good stuff can be generated here that might one day even end up in
Tim's documentation.

Dale

I don't consider myself a veteran, but here are my 2 cents:

1.) LAN: No big difference, just set RemoteCompression to 0,  and don't make really heavy
use of lookups.
Internet: Set RemoteCompression to 9, don't use lookups at all, if possible use
TClientDatasets instead of Tables and Queries, otherwise play with RemoteReadSize setting
and don't exspect performance wonders.

2.) None that I am aware of. When doing while-not-eof-next, a higher RemoteReadSize
setting usually gets better performance, but that applies to TEDBQueries also.

3.) This works in EDB the same way it has in DBISAM. I'm still doing it this way. In
DBISAM you could use autoinc fields instead, in EDB generated fields. I'm not aware of any
other methods, and I'm not in need of any.

4.) Windows 2003 server: Just place your DB folder (containing configuration file and
databases) where you like, if using only C/S don't share it, set the rights so that
edbsrvr.exe can access the folder.
Place edbsrvr.exe anywhere you like, run it. Done.
Vista: Don't have a clue, but it can't be that different.

5) I'm not deploying applications on clients. They are on a shared folder on the server,
there is only a link on the clients, makes updating a lot easier. For Internet
applications, I'm placing them in the programs folder, and a connection inifile in the
users folder.

Heiko

Hi Heiko:

Thanks for the reply.

2) Regarding Tables, I was under the impression that Client/Server was mainly Query
territory.  But I guess since the server is only handing out the rows of data that are
needed (based on RemoteReadSize), using tables should work fine as well.


4) If I understand you correctly, as long as the client can see the server, and the server
can see the datafiles, then it should work?  


5) Using DBISAM I usually run all the clients from a shared folder too.  But clearly I
need to rethink that with a remote connection.


Anyone else have any thoughts (see original post?)

Dale

Dale,

> The ElevateDB manual covers a lot of ground on "what" things are.... but
> does not say much on "how" they should be used.  (unless I'm looking in the wrong spot).
> Unless you already have the whole Client/Server/SQL thing down, its hard to know where to
> start.... and also what a good design looks like.

Have you seen the "cdcollector" example application that ships with EDB?
Also, you can find "Client-Server Application Tutorial" at:
http://www.elevatesoft.com/manual?action=mancat&id=edb2&product=b&version=2006&category=1


--
Fernando Dias
[Team Elevate]

Hi Fernando:

>Have you seen the "cdcollector" example application that ships with EDB?
>Also, you can find "Client-Server Application Tutorial" at:
>http://www.elevatesoft.com/manual?action=mancat&id=edb2&product=b&version=2006&category=

Yes, both the cdcollector and tutorial have been very helpful.  I'm just getting started
with my first Client/Server app using ElevateDB and am hungry to devour as much real world
information that I can get.  The newsgroups have also been very helpful.

Thanks,

Dale

Dale,

<< 2) Regarding Tables, I was under the impression that Client/Server was
mainly Query territory.  But I guess since the server is only handing out
the rows of data that are needed (based on RemoteReadSize), using tables
should work fine as well. >>

Correct.

<< 4) If I understand you correctly, as long as the client can see the
server, and the server can see the datafiles, then it should work? >>

Correct.

--
Tim Young
Elevate Software
www.elevatesoft.com

Dale,

<< 1.  What issues are important when designing for remote access (ie:
internet), and how to address them? >>

The main thing to avoid is chattiness in the application, which means that
lookup fields should be avoided, should be used against local tables, or
should use the LookupCache=True property value so that the values are cached
locally for the duration of the client application process.  You should also
avoid using Calculated fields that cause any navigation in other datasets,
because this will result in more chattiness between the client application
and the ElevateDB Server.

<< 2. What are the pitfalls in using TEDBTables in a C/S app.?  Or are there
any?  (I know this is a really basic question... but having no experience in
the word of servers, I have no idea). >>

There really aren't any with EDB, except for the above.  OnFilterRecord is
even very fast now with EDB because it is handled entirely on the
client-side, as opposed to how it worked with DBISAM.

<< 3.  How to set up a key field so that a unique key is generated when a
new record is posted.  With DBISAM, I would just create a key in the
OnBeforePost event is stuff it in the field.  But I suspect there are better
ways to do this with ElevateDB, what are they, and how to do it? >>

There are two "best" ways:

1) Use an IDENTITY column, and specify the seed and increment values.
2) Use a a BEFORE INSERT trigger that does the same type of logic, only with
your own table that is used to dish out the new values.

These two are best because they work independently of whether you are using
SQL or dataset methods (Insert/Append), and they are always handled entirely
server-side.

<< 4.  What are the best practices when deploying your ElevateDB server app
on a Vista machine, or how about Windows 2003 server.  What goes where, and
what permissions should be set.

5.  Same thing when deploying the client app? >>

These have already been covered by another response, so I'll leave them
alone.

--
Tim Young
Elevate Software
www.elevatesoft.com