Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » ElevateDB Technical Support » Support Forums » ElevateDB General » View Thread |
Messages 1 to 7 of 7 total |
Best Practices |
Mon, Nov 10 2008 1:48 PM | Permanent Link |
Dale Derix | 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 |
Mon, Nov 10 2008 6:49 PM | Permanent Link |
Heiko Knuettel | 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 |
Tue, Nov 11 2008 9:17 AM | Permanent Link |
Dale Derix | 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 |
Tue, Nov 11 2008 10:54 AM | Permanent Link |
Fernando Dias Team Elevate | 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] |
Tue, Nov 11 2008 12:06 PM | Permanent Link |
Dale Derix | 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 |
Tue, Nov 11 2008 2:47 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | 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 |
Tue, Nov 11 2008 2:55 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@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 |
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 |