Recent

Author Topic: Multi user with a TDBF  (Read 5694 times)

christophe_D

  • New Member
  • *
  • Posts: 20
Multi user with a TDBF
« on: February 12, 2007, 10:32:31 am »
is it possible , to have more than 1 user with a TDBF ??

for example, if the base is on a "server" and 2 users write on base
is the 2 users see the change ? or it will have a probleme ??

thank for your help

WibblyTim

  • New Member
  • *
  • Posts: 46
    • http://www.wibblytim.co.uk
Multi user with a TDBF
« Reply #1 on: February 13, 2007, 07:16:19 pm »
AFAIK only 1 user at a time can access a TDBF table. It is locked until the table is released by a user, only then can another user access the table.

If you need to have more than 1 user at a time accessing your database then TDBF is not the way to go, it is a flat file database. My understanding is that even with relational databases, for example MySQL, only one user at a time can access a table.

If I am wrong I'm sure that someone more knowledgeable will let us know!  :wink:

ssamayoa

  • Full Member
  • ***
  • Posts: 163
Multi user with a TDBF
« Reply #2 on: March 25, 2007, 08:48:55 pm »
This has been a topic from early 70's.
Lets talk about TWO different things:

1. Multi-user access / isolation.
2. Refres data.

When two users can share the same data is "multi-user access". At this time I haven't heard of any database (relational or flat file based, server or peer based) which cant hace multi user access. With TDBF you can have multi-user access (AFAIK still dont full tested but it works).

Isolation means how much of the changes on the database of other users affects you. Relational databases (such Oracle, Firebird, DB2, etc.) support at least two isolation modes

- Read commited.
- Repetable read.

I have no time (and this shouldnt be the place to do that) to go into this topic because has been treated so long before me (just do a sear on yahoo or google -which you prefer- about "transaction isolation") but TDBF support none, the only it support its called "dirty read" which means any commited or uncommited changes of other users are visible to your (transaction) user.

On the other hand, refresh data is what I thimk you mean and I add an example:

User A reads customer X record.
User B also reads customer X record.
User A changes name and post the change.
User B doesnt see the change made by user A until he/she REFRESH the record.

Then, if user B also changes the name value he/she will override what user A has writen.

This is known as lost update and has to do more with concurrent update access than muti-user capabilities of databases. Even in high end RDBMS such Oracle, DB2, M$ SQL Server, Firebird, etc. can happend. It is not about how database manages concurrency but how APPLICATION does.

If you are interested on this subject drop me a line to: sergiosamayoa (-at-) icon (.dot.) com {dot} gt

This is a very often question on all forums I read and may be is time to write a white paper about it.

Regards.

 

TinyPortal © 2005-2018