Improve company productivity with a Business Account.Sign Up


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

Free Tool: Site Down Detector

Helpful to verify reports of your own downtime, or to double check a downed website you are trying to access.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

A lot of questions regard threads in Delphi.   One of the more specific questions is how to show progress of the thread.   Updating a progressbar from inside a thread is a mistake. A solution to this would be to send a synchronized message to the…
This article explains how to create forms/units independent of other forms/units object names in a delphi project. Have you ever created a form for user input in a Delphi project and then had the need to have that same form in a other Delphi proj…
From store locators to asset tracking and route optimization, learn how leading companies are using Google Maps APIs throughout the customer journey to increase checkout conversions, boost user engagement, and optimize order fulfillment. Powered …
A query can call a function, and a function can call Excel, even though we are in Access. This is Part 2, and steps you through the VBA that "wraps" Excel functionality so we can use its worksheet functions in Access. The declaration statement de…

579 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