Board index » off-topic » Re: deadpoint, Michael Harris, Bill Todd, and ALL. The multiple records are still there. Somebody can help? (Multithreaded paradox table access)

Re: deadpoint, Michael Harris, Bill Todd, and ALL. The multiple records are still there. Somebody can help? (Multithreaded paradox table access)


2003-12-02 01:40:04 AM
off-topic17
if you open the table with Paradox or DBExplorer, are the records duplicated
?
"Alex" < XXXX@XXXXX.COM >a écrit dans le message de
Quote

"Alex" < XXXX@XXXXX.COM >wrote:
>Here is the screenshot (the code is patched as you said):
>www25.brinkster.com/alex99933/screenshot.jpg

Ooops. Sorry. They don't allow direct linking :(
So go to www25.brinkster.com/alex99933/db_test.html and click on
"SCREENSHOT".

 
 

Re:Re: deadpoint, Michael Harris, Bill Todd, and ALL. The multiple records are still there. Somebody can help? (Multithreaded paradox table access)

Hi Alex,
Have not had time to look any further, but I can say that the data was
corrupted in the TQuery, the grid does not appear to be the primary source
of the problem.
I suspect it may be a locking problem judging by the timing issues reported
by others, i will turn off oportunistic locking and see how it goes.
Will report back later.
That failing it may be possible to work around the problem by batching up
groups of updates and using critical sections or semaphores.
Other option may be to obtain an exclusive lock on the table when inserting
and cache any updates when the grad is updating.
"Michael Harris" < XXXX@XXXXX.COM >wrote in message
Quote
I would not have mentioned there is no problem here if there was..

NOTE:
I mentioned the update speed where you had 'random(5000)'
Many test revealed this NEVER caused a problem 'here'.

changing the sleep time to 'random(50)' Did occasionally detect duplicate
data in the Grid.
However, Refreshing the data ( fetchig the data again) indicated NO
duplicate records in the grid.

So, if the refresh fixed the grid data. It is NOT possible (in my test)
the
data was overwritten in the table between fetch (select) statements.
Therefore, the issue MUST be in the controls. TQuery / TDataSet /
TDataSource/ TDbGrid or whatever.

The point is, The data in the Table itself IS NOT corrupt.

Maybe there is some issue in your or my BDE settings not explored.

--
Michael


 

Re:Re: deadpoint, Michael Harris, Bill Todd, and ALL. The multiple records are still there. Somebody can help? (Multithreaded paradox table access)

Alex wrote:
Quote
"JM Granier" < XXXX@XXXXX.COM >wrote:

>if you open the table with Paradox or DBExplorer, are the>records duplicated?


If I do that when the writing thread are stopped the query in SQLExplorer return right results, of course.
What is the valöue of RequestLive property of the select TQuery? if
True, try setting to false and see if something changes.
--
Gert
 

{smallsort}

Re:Re: deadpoint, Michael Harris, Bill Todd, and ALL. The multiple records are still there. Somebody can help? (Multithreaded paradox table access)

"deadpoint" < XXXX@XXXXX.COM >wrote:
Quote
Will report back later.
I'm waiting ;-)
Quote
That failing it may be possible to work around the problem by batching up
groups of updates and using critical sections or semaphores.
I can do that. But from my point of view it's not a good solution.
And nevertheless my target is to find the problem not to mask it with some magic.
I'll be thankful to anyone who can help me with it.
Thank you.
 

Re:Re: deadpoint, Michael Harris, Bill Todd, and ALL. The multiple records are still there. Somebody can help? (Multithreaded paradox table access)

Alex
As I mentioned, My sample code was not complete due to time constraints.
However, Having a little time this morning, I believe it is now sorted out.
Still, the sample code is not fully tested.
steps :
1 : create a directory for each thread.
2: assign the directory to the thread,
leave the main thread using default privat dir.
TAsyncQueryThread
FSes->PrivateDir = GetPrivateDir( ) + "\\Async";
TUpdateQueryThread
FSes->PrivateDir = GetPrivateDir( ) + "\\Update";
Helps to isolate the transaction level.
Under the same conditions. I cannot reproduce the issue even with lowering
the delay time.
Sleep(random(100)); // we are in a hurry ...