mikek@col.hp.com (Mike Karin) (07/07/90)
I'm posting this for a friend. He has put together a rather elaborate database system for the real estate market using Borland's Paradox. He has run into a problem trying to make this system work on network with concurrent users. There are several multi-table forms that he uses in his application. The problem lies in Borland's scheme for locking the data. When a multi- table form is brought up, all tables in thier entirety are locked as opposed to the specific rows being accessed in these tables. (at least this is how I understand the problem) This means that the first time somebody on the network turns on his application and accesses the base level forms, all tables are locked up and other users cannot make any changes. He has asked Borland about this and gotten the response that this was a conscious decision on thier part to make it work this way. I forget what their reasoning was but it didn't apply to applications that were to be run-only. Very Unfortunate. If he were to abandon multi-table forms, he would have no problem. This obviously is not a very desirable option because much of the power of his application lies in the use of multi-table forms. My question is whether or not this same restriction is in other products such as RBase for DOS. I have looked at the documentation for V 2.11 and I *think* that this restriction isn't there. Can anybody shed some light on this? Mike Karin Hewlett-Packard Co. Colorado Springs Division mikek@col.hp.com
byock@umaxc.weeg.uiowa.edu (Bill Yock) (07/09/90)
From article <17630001@col.hp.com>, by mikek@col.hp.com (Mike Karin): > I'm posting this for a friend. > > He has put together a rather elaborate database system for the real > estate market using Borland's Paradox. He has run into a problem trying > to make this system work on network with concurrent users. > > There are several multi-table forms that he uses in his application. > The problem lies in Borland's scheme for locking the data. When a multi- > table form is brought up, all tables in thier entirety are locked as > opposed to the specific rows being accessed in these tables. (at least > this is how I understand the problem) This means that the first time > somebody on the network turns on his application and accesses the > base level forms, all tables are locked up and other users cannot > make any changes. He has asked Borland about this and gotten the response > that this was a conscious decision on thier part to make it work this > way. I forget what their reasoning was but it didn't apply to > applications that were to be run-only. Very Unfortunate. If he > were to abandon multi-table forms, he would have no problem. This > obviously is not a very desirable option because much of the power > of his application lies in the use of multi-table forms. When coediting tables with a Paradox multi-table form Paradox places a "form lock" on the tables. If other users want to modify the tables they must use the same form to access the tables. This is done to guarantee referential integrity of data by use of a data entry form. I agree that this can be restrictive in accessing data and I tend to try and overcome this problem by creating data entry forms that are as general as possible so that a variety of users can benefit from the forms referential integrity. Some PAL programmers try to overcome this restriction by creating their own multi table forms and manage the locking and referential integrity with programming code. I am glad that this feature is available in Paradox and I tend to find that it generally more beneficial than a hinderance. > > My question is whether or not this same restriction is in other products > such as RBase for DOS. I have looked at the documentation for V 2.11 > and I *think* that this restriction isn't there. I am not familiar with RBase for DOS but I wouldn't be surprised if it had a similar forms based referential integrity. This is an important issue for databases and I feel that the more the database can maintain the integrity itself the better. -- Bill Yock, Weeg Computing Center, University of Iowa, Iowa City, Iowa 52242 byock@umaxc.weeg.uiowa.edu