Go Premium for a chance to win a PS4. Enter to Win


Advice on applying TDatabase at application.

Posted on 2004-09-08
Medium Priority
Last Modified: 2010-04-05
Currently, I am developing an application.  This exe application will be used by several users at different PC, but connecting to a database sit on a server.

I always face error prompting "lock conflict".  Is it caused by the way I code the program ?  This is some of the examples I code in my program :-

First of all I have a data module where a TDatabase component is placed.



I have all my various forms pointing to this data module ( named "dm" ) 's database ( named "db" ).  I suppose this might cause deadlock ??

Please advise on how I should construct such kind of application in the aspect of database, especially when saving data.
Question by:ivylnm
  • 3
  • 2
LVL 17

Expert Comment

by:Wim ten Brink
ID: 12004595
Several Q's:

Which Delphi version?
You're using the BDE, right? Is it set up correctly to use a lock file on a fileshare in your network?
Which database type? (SQL Server, Oracle, Paradox)

If you're using the BDE, the BDE must create a file to keep track of locks in the database. If every user has his own application with BDE, then they must be set up to use a lock file on a shared folder. This is done by using the NetFileDir property of the database SESSION object. Best thing to do is adding a TSession to your datamodule, give it a name, set it up to point to a network folder and make sure your database and tables are looking at this session...

And perhaps upgrade to ADO with either SQL Server, Oracle or MS Access. Then these problems are less likely to happen.

Author Comment

ID: 12012423
I am using Delphi 7 developing application and connecting to Interbase database, using TDatabase, TQuery components.

LVL 17

Expert Comment

by:Wim ten Brink
ID: 12014616
Well, since you're using the BDE, you need to set up a shared folder for the lock file. Doesn't matter if you're using Paradox, DBase, Oracle or Interbase. If you share a database connection through the BDE to a database, you need to share the lock file amongst ALL users or else the BDE gets conflicts. (Because the BDE on System A is saying that record X is unlocked while the BDE on system B has this record locked...)
With Interbase, you might want to change to the Interbase database components instead. They're more native.

In the past, I've solved these kinds of problems by creating a multi-tier solution. That way, you only have one system that needs to keep track of all the locks and database transactions. It does require a lot of additional code and a dedicated system as middle-tier system. The advantage however is that none of the clients would need to install the InterBase client software, though...

Author Comment

ID: 12023164
So do you mean that using Interbase components would be much more suitable in this kind of application ?

Can you show me details of the second paragraph of your comment ? I don't quite understand.
LVL 17

Accepted Solution

Wim ten Brink earned 500 total points
ID: 12026086
The InterBase components communicate directly with InterBase itself, not through the BDE or whatever else. Thus you have a bit of a performance gain.

About multi-tier applications, there are many alternatives for this but it means you have to create two applications. It is very useful for medium to large companies where many users must share the same database. You will have an X amount of client PCs and one PC that is set up as middle-tier. (MT) Then another PC that is used as database server, although middle-tier and database server could be the same system, if you want to conserve resources.

For the MT you create an application that will arrange the communication between the clients and the database (server). The communication from the MT to the database is simple throught the BDE, though the InterBase components or perhaps even through ADO. The communication with the clients can be either through simple TCP/IP, DCOM or COM+ or by SOAP/Webservices. It just depends on what you favour as a solution. If you prefer TCP/IP then the MT is just an executable that you start once, which then waits for communications from the client(s). With DCOM or COM+ you just develop COM objects which get activated by the system. The client just activates these COM components remotely, the component then starts processing. SOAP/Webservices is a bit comparable to COM+ but the difference is that it's more XML-based and often combined with a webserver. Basically, a SOAP server is just a special kind of ISAPI DLL that's used by IIS to provide webpages to clients. (In these cases, not real webpages but XML files.)

But Multi-tier technologies are a bit hard to learn if you're completely inexperiences with it. It easily takes about 3 to 6 months before you finally get a good understanding of the technology. Not because it's complex but because it is a very large topic. And you probably end up learning a lot of stuff about COM and ActiveX.

My personal preference is COM+, btw. Delphi 7 doesn't support SOAP as well as I've hoped. (Delphi has some compatibility problems since they didn't exactly follow the SOAP specifications.) To send data from server to clients I used ADO for the recordsets but that's because it's the easiest technique if you're using SQL Server. With InterBase you would use Midas/ClientDataset or perhaps you convert the recordsets to XML data and send the XML to the client.

The advantage for the clients is that they don't require any database logic. So no InterBase clients on their systems that need to be configured. All the client applications need to know is the server with the Middle-tier software. The middle-tier then provides them the information in whatever format they prefer. Basically, all the client would need is a single executable. Your application.

The big advantage is that technically, only one system is talking to the database thus that single system can keep track of all the locks. The disadvantage is that it takes a lot of study, a lot of experimenting and a new way to develop software. Basically, you're dividing the system into multiple logical blocks. The clients who just display the data, the middle-tier that does most of the processing of the data and the database server that just stores everything. Complex, but powerful. (Besides, if you ever need to use a different database, all you have to change is the middle-tier. None of the users would see any difference.

Featured Post


Modern healthcare requires a modern cloud. View this brief video to understand how the Concerto Cloud for Healthcare can help your organization.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Have you ever had your Delphi form/application just hanging while waiting for data to load? This is the article to read if you want to learn some things about adding threads for data loading in the background. First, I'll setup a general applica…
Introduction I have seen many questions in this Delphi topic area where queries in threads are needed or suggested. I know bumped into a similar need. This article will address some of the concepts when dealing with a multithreaded delphi database…
Exchange organizations may use the Journaling Agent of the Transport Service to archive messages going through Exchange. However, if the Transport Service is integrated with some email content management application (such as an anti-spam), the admin…
How to fix incompatible JVM issue while installing Eclipse While installing Eclipse in windows, got one error like above and unable to proceed with the installation. This video describes how to successfully install Eclipse. How to solve incompa…
Suggested Courses

885 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question