Hi all

I once wrote about my problem "Could not update; currently locked"
http://groups.google.com/group/comp....53b984344 234

The problem is, that there is a saver, cashing data, and a summariser
which goes though data for the last half our and put them in another
table.
There are 2 threads doing this, but they cannot work at the same time.
If I save data every 20 ms, then the "Could not update; currently
locked" error occurs.
AFAIK it should be possible for multiple users to access one *.mdb
file - or am I wrong?

I attach some code here, it that helps.

CoInitialize(nil);
FConnection := CreateOleObject('ADODB.Connection') as _Connection;
FConnection.CursorLocation := adUseServer; { Client if you need to
use recordcount!!!! }
FConnection.Open('Data Source=' + FDatabaseName, FUsername,
FPassword, 0);
FRecordset := CreateOleObject('ADODB.Recordset') as _RecordSet;

var
FRecordset.Open(sSQL, FConnection, adOpenForwardOnly,
adLockReadOnly, adCmdText);
and...
FConnection.Execute(sSQL, aI, 0);
// this fails sometimes, if the threads by accident works at the same
time, even that they are working on different tables.

WBR
Sonnich

On Wed, 22 Apr 2009 09:51:24 -0700 (PDT), jodleren <sonnich (AT) hot (DOT) ee>
wrote:

You don't give a lot of information, but to me it seems running some
query every 20 ms (that's milliseconds) is insane. Copying the data to
another table is a violation of relational database design principles.
You may want to re-think your application and database design first.

-Tom.
Microsoft Access MVP

Hello

This is an existing system, I cannot rethink the system. Most cases
here are not new designs, but existing systems.... which we cannot
really change...

It works this way:

The programme (component) gets data from somewhere, and passes it on
to a thread - and I really do not know how often data come.
The saver caches data in an array in a saver thread, and the thread
then flushes data when present. Data are flushed to a table named
"states"

Next, the summariser thread goes into action every half our, and
summarised data (if present) for that half hour (or more). The thread
reads from states, data from the last record in states_summarised
until the end. These date are them added up etc and saved into
states_summarised.
Then, it finally deletes data from states, upto the time before this
summarisind - the idea is to know at all times, what state we had
before.

So, what I have:

saver: insert into states values(....)

summariser: select * from states where record_time > .....
insert into states_summarised values(....)
delete from states where record_time < .....

WBR
Sonnich


On Apr 23, 4:41*pm, Tom van Stiphout <tom7744.no.s... (AT) cox (DOT) net> wrote:

Is it a big secret as to what application you might be using? Maybe
Pythia could tell us?

On Apr 22, 12:51*pm, jodleren <sonn... (AT) hot (DOT) ee> wrote:

"lyle fairfield" <lyle.fairfield (AT) gmail (DOT) com> wrote

As far as I know, neither Access nor Jet is multi-threaded and I never even
speculated as to how Jet might act/react when used by a multi-threaded
application.

Maybe the poster could go via Delphi to the Oracle for the answer.

Larry Linson
Microsoft Office Access MVP





__________ Information from ESET Smart Security, version of virus signature database 4031 (20090423) __________

The message was checked by ESET Smart Security.

http://www.eset.com

On Apr 23, 11:08 am, lyle fairfield <lyle.fairfield (AT) gmail (DOT) com> wrote:

I think that your oracular reference while seeking divine inspiration
in determining the application in question is not a good analogy for
the following reason. Given the description by, I believe, Herodotus
of how the extremely profitable Oracle at Delphi worked in practice,
the Oracle was actually clued in by the gods in an authentic way that
was truly mystical and marvelous or she had an espionage network that
was second to none. I prefer to suspect the latter. I don't discount
divine revelation as a possibility in determining jodleren's
application. The doubts I have about your analogy are more about the
reach of your spy network :-).

James A. Fortune
CDMAPoster (AT) FortuneJames (DOT) com