Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 232
  • Last Modified:

Making Delphi code multiuser when printing reports with QReports

I am converting some Delphi 5 code to be multi-user. There are various modules.
Several appear to just print particular reports via QReports. Others are for data entry.

Can any Experts give me advice as how to approach the multiuser locking scenario?

As one module might be locking a record for some action what is the issue if you choose to print a report and QReports opens up the entire table.

Do I just ignore it?
Lock the entire table?
Or something more subtle?

n.b. There isn't much data and the time taken to print a report is 5 seconds max. Nothing in the system is locked for very long.

With thanks,


  • 4
  • 4
1 Solution
If one module has locked one or more records and you open that table entirely then the record (which is locked) will have the last commited value. The issue might be that after few microseconds the locked record is released and have the value changed. But I don't think this is an issue because at the time of request for print you get the latest commited values.

In summary, for reporting, you need not to place any write lock. However, you can place read lock.
edhastedAuthor Commented:
So you are suggesting:

1. Activate Read Lock
2. Print Report
3. Deactivate Read Lock

The sequence you understand it depends on the DBMS you use. e.g. in client-server application when you request data it creates a cursor and sends back that cursor to the client. Now the read lock required when it creates the cursor and reads the data from server; once it is created and populated, the lock should be released. Becasuse holding the lock until you print the report is not wise solution.

But if you are using live tables then you will need to hold the lock until you print the report. But for printing live tables must be avoided.
Independent Software Vendors: We Want Your Opinion

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

edhastedAuthor Commented:
So the "Cursor" is Delphi's notional way or working out which record you are on.
In none of these programmes are there any datagrids. All people are doing is filliing in forms, posting data and then generating reports.
We're using Paradox Tables via the BDE.

If we shouldn't print reports from live data what should I do?
a. Lock the table.
b. Copy to data to temp table.
c. Unlock Table
d. Run report from the newly created Temp table
Given there are no datagrids I haven't got my head roud the comcept of the "cursor" or is this something that Delphi works out for itself.

Paradox doesn't support cursors. Moreover, BDE supports only tiDirtyRead for TransIsolation level (means it will show uncommited data also) so whatever lock you place it will show the same data at first place. So the ideal solution is to

1. Open table
2. Place a readlock
3. Refresh the table
4. Unlock the table
5. Print report

Give a close look why we should go for this approach.
1. Read lock will ensure that no one is editing the table
2. when we first opened the table, the table was unlocked and it has dirty data. so after placing a read lock and refresh, the table will have the latest data and no dirty records (because we have locked it first so noone else can make it dirty)
3. Because we the correct data there is no use to hold the lock
4. proceed to print the report
>>As one module might be locking a record for some action what is the issue if you choose to print a report and QReports opens up the entire table.

In general for the reprot purpose there is no need to worry about the record is locked or not. You are not going to edit the record when we generate a record. Mosly the report is interacting with the Tquery to get the result.

For the multiusers of any programs, I never had a problem with the record lock.
The record lock happens when one recrod is in the edit state for one user and another user is trying to edit the same record, the second user will get the record lock message.But for the report the edit state will never occur, it will be in in the read only state.

For the reprot what ever record is saved/commited will come in the report. No need to bother(most cases) what the user is doing with the record when the time of generating a reprot.

Hope I am in the right way to your question
In brief, for the report purpose, no need to bother about the record lock even in multiuser enviorment.

Hope this helps you.
edhastedAuthor Commented:
So the approach is that there is no need to lock for printing purposes but it does make sense to do a locked refresh prior to printing to ensure the data is up to date?

Yes, because the idea behind using such an approach it is to retrieve committed data. However, most developer doesn't care abt it and the result is dirty data (i.e. the data that is saved but not commited and also can be rolled back)
edhastedAuthor Commented:
Thank you for this practical help as the real world answer isn't the intuitively logical one.

Ed Hasted

Featured Post

Free Tool: Subnet Calculator

The subnet calculator helps you design networks by taking an IP address and network mask and returning information such as network, broadcast address, and host range.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

  • 4
  • 4
Tackle projects and never again get stuck behind a technical roadblock.
Join Now