MDI Forms and Paradox over Network
I need to build an app that can work with 2 on a network, using 2 MDIChildForms accessing 2 different TTables.
The user needs to edit or insert records in both MDIChildForms at the same time.
The Problem is:
If I add only 1 TDatabase to my datamodule, and link my TTables to it, the user can only start one Transaction at one form, when he tries to insert/edit a record on the other window a message comes up, "A user transaction is already in progress".
Using TDatabase is the best way to make a MDI Paradox based program work on a windows network?
Do I need to add 1 TDatabase for each TTable component on my datamodule?
If so, can I do it at runtime?
Samples are welcome!
Thanks,
VSF
hereim@ig.com.br
www.victory.hpg.com.br
www.enge.cjb.net
The user needs to edit or insert records in both MDIChildForms at the same time.
The Problem is:
If I add only 1 TDatabase to my datamodule, and link my TTables to it, the user can only start one Transaction at one form, when he tries to insert/edit a record on the other window a message comes up, "A user transaction is already in progress".
Using TDatabase is the best way to make a MDI Paradox based program work on a windows network?
Do I need to add 1 TDatabase for each TTable component on my datamodule?
If so, can I do it at runtime?
Samples are welcome!
Thanks,
VSF
hereim@ig.com.br
www.victory.hpg.com.br
www.enge.cjb.net
Use a TSession object...
firsttime->listening ... not time yet
VSF, do you have the TTable active while in design mode? If so, this may be the cause of the trouble. First compile the project, quit Delphi and try to run the exe. It should work then... (I hope).
The TSession is not necessary but it could be wise to use it.
The TSession is not necessary but it could be wise to use it.
hi again,
guessing you are using two ttable instances,
and so, if one instance is in edit mode (or in transaction), the other instance can't do this for the same record.
if so, then i would use a tdatamodule, where is placed one tableinstance, and the mdi-forms are connecting to it with a datasource instance each.
if not so,
then just ask the tdatabase, if it is intransaction,
if not then starttransaction, if yes then do not starttransaction, because a transaction is already established.
if you will use different transactions then you may use more tdatabases.
meikl ;-)
guessing you are using two ttable instances,
and so, if one instance is in edit mode (or in transaction), the other instance can't do this for the same record.
if so, then i would use a tdatamodule, where is placed one tableinstance, and the mdi-forms are connecting to it with a datasource instance each.
if not so,
then just ask the tdatabase, if it is intransaction,
if not then starttransaction, if yes then do not starttransaction, because a transaction is already established.
if you will use different transactions then you may use more tdatabases.
meikl ;-)
The problem is that Delphi (5) does not release everything when you close the database connection (TDatabase.Active property) in designtime (bug in BDE?). At least that is what I experienced. I had to close Delphi before I could properly access the database again.
To avoid this problem while testing in Delphi, keep TDatabase.Active false. In the TMDICild.OnCreate event set Database1.Active to true, so it will only connect at runtime.
To avoid this problem while testing in Delphi, keep TDatabase.Active false. In the TMDICild.OnCreate event set Database1.Active to true, so it will only connect at runtime.
hehe, eps, catched you :-))
Hardly anyone responds the last 2 days...
yup, thats true, happens to me too :-(
Hi VSF,
meikl :-)
epsilon :-)
There is two different tables. Seems transaction started on insert or on edit event. The way is to start transaction just before post event and commit it after post. So, it will take very short period of time.
May be I miss somethig :-)
-----
Igor
meikl :-)
epsilon :-)
There is two different tables. Seems transaction started on insert or on edit event. The way is to start transaction just before post event and commit it after post. So, it will take very short period of time.
May be I miss somethig :-)
-----
Igor
hi igor :-)
hi all :o)
ASKER
Ok.
So I should add one TDatabase for each table in my datamodule, is that right?!
(I think Tdatabase can only support one transaction to be opened at a time.)
Adding one Tdatabase for each table will damage too much memory? Hope not!
Epsylon:
My Tdatabase is active false, just like my Ttables in desing time.
I use Tdatabase.connected:=true;
So I should add one TDatabase for each table in my datamodule, is that right?!
(I think Tdatabase can only support one transaction to be opened at a time.)
Adding one Tdatabase for each table will damage too much memory? Hope not!
Epsylon:
My Tdatabase is active false, just like my Ttables in desing time.
I use Tdatabase.connected:=true;
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Why not putting the TDatabase and TTable on the MDIChild window? This also means that the DataModule will be empty. And I think you need a TSession on the MDIChild window.
yould be also a choice, eps,
tsession i guess is not needed,
if no one exists the default session is taken
meikl ;-)
tsession i guess is not needed,
if no one exists the default session is taken
meikl ;-)
ASKER
One table can be accessed from more than one form for reading and accessed by a single form for writing!
The form are not AutoCreate
That's why I'd rather put the Ttables on a datamodule.
The big problem will be add a Tdatabase for each Ttable.
I'm seriously thinking of migrating to Interbase ASAP.
VSF
The form are not AutoCreate
That's why I'd rather put the Ttables on a datamodule.
The big problem will be add a Tdatabase for each Ttable.
I'm seriously thinking of migrating to Interbase ASAP.
VSF
this will be a wise decission, because there you have a real transaction tracking
It's good idea to use Interbase and be independent from BDE.
Anyway, starting transaction on BeforePost and commit it AfterPost is the way to avoid of transcation jam. Let say that transcation started when user press "Save" button and finished immediatly after data sended to database. Do you beleave that user able to switch to another form and press there "Save" button while data still not commited in first transaction? I think no.
Let look at idea to start transaction AfterInsert or AfterEdit dataset. Can you be sure that user doesnt change it's mind and will save entered data? But transaction will be started and takes server's resources to keep current version of database while user doesn't press "Save" or "Cancel" button.
So, this way will produce long transaction activity and may be a chance that it is fully unusual (user press "Cancel").
Just few words about transaction usage:-)
-------
Igor.
Anyway, starting transaction on BeforePost and commit it AfterPost is the way to avoid of transcation jam. Let say that transcation started when user press "Save" button and finished immediatly after data sended to database. Do you beleave that user able to switch to another form and press there "Save" button while data still not commited in first transaction? I think no.
Let look at idea to start transaction AfterInsert or AfterEdit dataset. Can you be sure that user doesnt change it's mind and will save entered data? But transaction will be started and takes server's resources to keep current version of database while user doesn't press "Save" or "Cancel" button.
So, this way will produce long transaction activity and may be a chance that it is fully unusual (user press "Cancel").
Just few words about transaction usage:-)
-------
Igor.
ASKER