Also - what happens with queries?

Roy Lambert

Roy,

<< I can't find the answers in the pdf manual so I'm asking the guru. I'm
looking through the code of an existing app to open memory tables
exclusively. I also opened the dbisam.lck file in notepad to see what's in
it. I can spot all of the disk tables, most of the memory tables are created
exclusively but one (SandT) isn't, and I can't see it anywhere. >>

In-memory tables are handled in an in-memory dbisam.lck file, not in the
dbisam.lck on disk.

<< What is actually stored in dbisam.lck for memory tables? I presume,
unlike disk tables, there would be one entry per instance of the application
creating the memory table? >>

Same thing is stored for both disk-based and in-memory tables.  The only
difference is where the dbisam.lck is stored, just like with the actual
tables.

--
Tim Young
Elevate Software
www.elevatesoft.com

Roy,

<< Also - what happens with queries? >>

Queries simply use tables just like you do directly with a TDBISAMTable
component, so nothing is different.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim

>In-memory tables are handled in an in-memory dbisam.lck file, not in the
>dbisam.lck on disk.

So that means (I hope) that when the app closes the in-memory dbisam.lck file also disappears - if so I now understand why my app has run a long time without hitting the 4096 barrier - that many emails in a single user session (not one of your's Tim) would be pushing it

Roy Lambert

Roy,

<< So that means (I hope) that when the app closes the in-memory dbisam.lck
file also disappears - if so I now understand why my app has run a long time
without hitting the 4096 barrier - that many emails in a single user session
(not one of your's Tim) would be pushing it >>

Nah, I don't think I've ever come even close to that.  However, I have come
close to 512 or so.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim


I've finished messing with table structures and I'm back to coding. I've altered most of the in-memory tables to exclusive access but there are a couple used for lookup/display only, created when the app starts, that I can't set exclusive. What's the story on ReadOnly := True - is that also added into the dreaded dbisam.lck.

If so - please stop doing that

Roy Lambert

Roy,

<< I've finished messing with table structures and I'm back to coding. I've
altered most of the in-memory tables to exclusive access but there are a
couple used for lookup/display only, created when the app starts, that I
can't set exclusive. What's the story on ReadOnly := True - is that also
added into the dreaded dbisam.lck. >>

Yes, it is.  Remember, read-only is only a table cursor concept, and DBISAM
still has to open the table in read/write mode at the physical level.
Multiple table cursors share the same physical table in the engine.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim


OK my brain had obviously gone to sleep and I forgot other idiots or parts of my system could open it with write access.

Roy Lambert