Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 3 of 3 total
Thread Clarification on Memory Tables
Mon, Nov 20 2006 7:08 PMPermanent Link

"Adam H."
Hi,

I think I understand this, but just wanted clarification before I stuffed up
something. Smile

Running DBISam 4

In my application - I run various reports, that do "queries on queries". The
SQL looks like:

--------------------------
select afield, anotherfield
into Memory\tmp1
from Mytable
;
select sum(afield), anotherfield
from Memory\tmp1
group by anotherfield
--------------------------

OK - the real sql's look a little more complex, but you get the idea. So
far, I have been running DBISam in local mode. I only have a problem if I
use the same memory table name in more than one TDBISamQuery table, when
more than one is opened from the same application. (Which is what I would
expect). My questions are:

1) If I run queries that insert data into memory using client/server mode
(off a DBISam server) - where two users on different machines run the same
query, with the same memory table name - I assume there are two seperate
processes running on the DBISam server, and this will not cause any
conflicts. (ie - 2 seperateconnections mean 2 unique seperate memory
'areas')

If this is correct - is this the case if I have two users, on two machines,
logging into DBISam server using the same username & password?

and...

2) If I have users running of Terminal Service Sessions (using Local mode) -
does each user have their own unique memory table area too?

From what I can gather, all scenario's above should be seperate - the only
problem being if the *same* application instance tries to run queries
inserting into the same tablename - but I just wanted to clarify.

Thanks

Adam.

Tue, Nov 21 2006 4:13 AMPermanent Link

"Jose Eduardo Helminsky"
Adam

I think you will wait for Tim answer but...

> 1) If I run queries that insert data into memory using client/server mode
> (off a DBISam server) - where two users on different machines run the same
> query, with the same memory table name - I assume there are two seperate
> processes running on the DBISam server, and this will not cause any
> conflicts. (ie - 2 seperateconnections mean 2 unique seperate memory
> 'areas')
>
> If this is correct - is this the case if I have two users, on two
> machines, logging into DBISam server using the same username & password?

Yes, this is correct. Two processes, two sessions, and therefore two memory
tables created, one for each user.

> 2) If I have users running of Terminal Service Sessions (using Local
> mode) - does each user have their own unique memory table area too?
Yes, each user has it own memory area.

Eduardo

Tue, Nov 21 2006 1:18 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Adam,

<< 1) If I run queries that insert data into memory using client/server mode
(off a DBISam server) - where two users on different machines run the same
query, with the same memory table name - I assume there are two seperate
processes running on the DBISam server, and this will not cause any
conflicts. (ie - 2 seperateconnections mean 2 unique seperate memory
'areas') >>

It is threads, not processes, running on the database sever, but yes, you
are correct.

<< If this is correct - is this the case if I have two users, on two
machines, logging into DBISam server using the same username & password? >>

No, internally DBISAM keeps them separated by process ID, not user name.

<< 2) If I have users running of Terminal Service Sessions (using Local
mode) - does each user have their own unique memory table area too? >>

Yes.

--
Tim Young
Elevate Software
www.elevatesoft.com

Image