agim_bekaj
asked on
Stand-alone to client/server application (how to run stand-alone app on local network)
I have all ready done stand-alone Accounting Application. I am using Paradox databases and Delphi enviroment. Which is easiest way to run (convert) stand-alone as a client/server (or how to run my application on local network - 5 users)?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
I agree with Alex's recommendation. Start by moving to a real DBMS first. Hone your database skills, then take on the additional task of communications and n-tier operations.
Don't know much about Apollo, Advantage or NexusDB since I'm not that fond on those kinds of third-party database connection providers. I still have nightmares because of QuickReports, a report generator, because it just contained too many bugs to be really useful and the creators of this component set had their own view on component design and forgot about backwards compatibility... There are quite a lot of third-party tools that seem to be useful but most of them still have some nasty flaws.
Now, the database servers might be very useful but consider this: ADO is a very well-proven technology right now. Lots of people use ADO and ADO isn't limited to just Delphi. ADO is available on all W2K systems and better and has a pretty good performance. If you have a database that comes with an ADO driver, you could use that database quite easy in your application. You could consider ADO the more enhanced version of the BDE. Only difference is that it was created by MicroSoft, not Borland. Now, if Apollo, Advantage or NexusDB can be accessed through ADO then I don't see any problem with them. But if they require their own API calls or components then you might have some troubles if you ever want to migrate to another database system.
Borland comes with several default database connection methods. ADO is the most popular at this time, next to the BDE. Actually, my previous projects rely mostly on the BDE while I only use ADO for any new projects. (And I try to upgrade my BDE projects to ADO.) Then there is dbExpress which is useful when you want to create cross-platform applications. (Meaning that you could compile your application with Kylix too, probably.) If I'm not mistaken, the Interbase components are also platform-independant but they will limit you to a single database system: InterBase. But I don't need to develop cross-platform applications and I know that ADO is quite reliable at this moment. Besides, ADO is free. You only have to get some database server to work with it.
Btw. I do know there's an ODBC driver for Paradox. You could use ADO to connect to an ODBC source and let the ODBC connect to your Paradox tables. Not very pretty but perhaps nice alternative. But I would still suggest to move to a real DBMS system instead. Something that supports SQL and preferably transactions. Perhaps even a DBMS that supports things like views and stored procedures.
Now, the database servers might be very useful but consider this: ADO is a very well-proven technology right now. Lots of people use ADO and ADO isn't limited to just Delphi. ADO is available on all W2K systems and better and has a pretty good performance. If you have a database that comes with an ADO driver, you could use that database quite easy in your application. You could consider ADO the more enhanced version of the BDE. Only difference is that it was created by MicroSoft, not Borland. Now, if Apollo, Advantage or NexusDB can be accessed through ADO then I don't see any problem with them. But if they require their own API calls or components then you might have some troubles if you ever want to migrate to another database system.
Borland comes with several default database connection methods. ADO is the most popular at this time, next to the BDE. Actually, my previous projects rely mostly on the BDE while I only use ADO for any new projects. (And I try to upgrade my BDE projects to ADO.) Then there is dbExpress which is useful when you want to create cross-platform applications. (Meaning that you could compile your application with Kylix too, probably.) If I'm not mistaken, the Interbase components are also platform-independant but they will limit you to a single database system: InterBase. But I don't need to develop cross-platform applications and I know that ADO is quite reliable at this moment. Besides, ADO is free. You only have to get some database server to work with it.
Btw. I do know there's an ODBC driver for Paradox. You could use ADO to connect to an ODBC source and let the ODBC connect to your Paradox tables. Not very pretty but perhaps nice alternative. But I would still suggest to move to a real DBMS system instead. Something that supports SQL and preferably transactions. Perhaps even a DBMS that supports things like views and stored procedures.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
You can put your paradox tables on to a file server (NT etc0 and your application will work multi user at an acceptable speed for the number of users you are considering.
swift:
What do you mean with "ADO is not scalable"? ADO has been made to be scalable and is in use by many companies already. Quite a few webservers even depend on ADO to be scalable... And from personal experience I know that ADO combined with either Oracle or MS SQL Server can easily handle 20 to 100 users. More even if required. Keep in mind though that ADO isn't a database system but a database connector like the BDE.
JDuncan:
What you suggest is not very reliable. The company I work for had some very bad experiences with Paradox tables in shared environments. The biggest problem is scalability. But there is also the problem that Paradox tables can get corrupt if one of the users doesn't close his application correctly. Even with 5 users there is a high risk of getting corrupt tables with a possible huge data-loss. And then there's the nasty way that Paradox locks records. When a user is using a single record, Paradox doesn't just lock this record but also other records that are located close to this record in the file. This makes it quite hard to have multiple users update the tables.
What do you mean with "ADO is not scalable"? ADO has been made to be scalable and is in use by many companies already. Quite a few webservers even depend on ADO to be scalable... And from personal experience I know that ADO combined with either Oracle or MS SQL Server can easily handle 20 to 100 users. More even if required. Keep in mind though that ADO isn't a database system but a database connector like the BDE.
JDuncan:
What you suggest is not very reliable. The company I work for had some very bad experiences with Paradox tables in shared environments. The biggest problem is scalability. But there is also the problem that Paradox tables can get corrupt if one of the users doesn't close his application correctly. Even with 5 users there is a high risk of getting corrupt tables with a possible huge data-loss. And then there's the nasty way that Paradox locks records. When a user is using a single record, Paradox doesn't just lock this record but also other records that are located close to this record in the file. This makes it quite hard to have multiple users update the tables.
I'm talking 1000 to 20000 users ... I have a different definition of scalable. My "small" is ten time the size of your "large".
ASKER
JDuncan:
Can you give more details about Paradox tables on file server, because I tried but without success.
Can you give more details about Paradox tables on file server, because I tried but without success.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
You definitely want to have two phase commit also, which is not supported by Paradox.
The two phase commit means that records are locked only for the duration between your "startTransaction" and "Commit" (or "Rollback" on errors), so even when the DBMS locks an entire page there is a minimum of contention. It also means that your data model always has either all of the required changes for the transaction or none. No more partial updates where one table has updated data and the other one does not.
The two phase commit means that records are locked only for the duration between your "startTransaction" and "Commit" (or "Rollback" on errors), so even when the DBMS locks an entire page there is a minimum of contention. It also means that your data model always has either all of the required changes for the transaction or none. No more partial updates where one table has updated data and the other one does not.
ASKER