Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM General » View Thread |
Messages 11 to 18 of 18 total |
Problem changing DatabaseName property |
Sat, Jan 13 2007 12:39 PM | Permanent Link |
"Frans van Daalen" | "Bern Rudisill" <bernr@no-sp.am.exitcare dot com> wrote in message news:F2BBA35D-2031-45AD-AF63-4B2DC73EA2CF@news.elevatesoft.com... > > > Right now if I set the database to a folder that has read/write access > it sets readonly to false, if I then change the database to a folder > You are sure that if I set a table to readonly and connect it to a database with a connection to a read/write folder suddenly the readonly will be set to false??? I don't think so, hence you conclusion is not correct. > > I consider this to be inconsistant behavior in DBISAM > |
Sat, Jan 13 2007 4:20 PM | Permanent Link |
"Bern Rudisill" | Robert wrote:
> > "Bern Rudisill" <bernr@no-sp.am.exitcare dot com> wrote in message > news:F2BBA35D-2031-45AD-AF63-4B2DC73EA2CF@news.elevatesoft.com... > > > > > > I consider this to be inconsistant behavior in DBISAM > > > > Is your position that DBISAM should NEVER change the readonly > property? > > Robert NO that is not my position. Here is my position, each and every time DBISAM opens a table it should set the readonly property to the readonly attribute of the table, the the programmer should set the readonly property to true manually after each and every time a table is open if the programmer wants it that way. Right now DBISAM does the following (For the first 3 assume this is the first time ever the table was open) If the table is on a CDROM (which is readonly) then it marks the readonly property as true because it is readonly media. If the table is in a folder and either the folder or the actual table file (the .dat) is marked as readonly in the file system even though it is on read/write media (like a hard drive) then DBISAM it marks readonly as true. If the table is in a folder and it is not marked as read only in the file system then DBISAM sets the readonly property to true. Based on this DBISAM does some initial checking to see what to set readonly to the first time you open a table. What I want to know is why DBISAM does checking the first time you open a table but not subsiquent times? That is what is inconsistant. If I use the same table component to various open tables that are on both readonly media and read write media, I as the programmer really have to way of knowing if it is readonly or not since DBISAM is inconsistant. Like I said if you first open a table on a cdrom then DBISAM marks the table as readonly (which I agree with), now I use the same table component and open a table on the hard drive (which is NOT marked as readonly) then DBISAM still says it is readonly even though it is not and I as the programmer have to expecilicy set the readonly back to false, but how do I really know if the file is truely readonly or not? Am I suppose to write another routine that say ok I opened tablex now get the file system attribs for tablex and see if it is readonly or not and set DBISAM accordingly? What I am suggesting is DBISAM should always be consistant each and everytime you open a table, if it is on readonly media or marked as readonly in the file system then the readonly property of the table should be true (then if the programmer checks the readonly property right after opening the table then you know it is on readonly media or it is marked as readonly), and if the table is not on readonly media and it is not marked as readonly in the filesystem then the readonly property should be set to true (then if you check the readonly property right after opening the table then you know the actually stats of the file, then if you truly want it readonly then the programmer should mark it as readonly) This came about because after we upgraded to DBISAM 4.25 build 2 and we updated about 300 customer, we started having a lot of access denied errors and finally tracked it down to this inconsistant behavior. Bern -- |
Sat, Jan 13 2007 4:38 PM | Permanent Link |
"Bern Rudisill" | Frans van Daalen wrote:
> > "Bern Rudisill" <bernr@no-sp.am.exitcare dot com> wrote in message > news:F2BBA35D-2031-45AD-AF63-4B2DC73EA2CF@news.elevatesoft.com... > > > > > > Right now if I set the database to a folder that has read/write > > access it sets readonly to false, if I then change the database to > > a folder > > > > You are sure that if I set a table to readonly and connect it to a > database with a connection to a read/write folder suddenly the > readonly will be set to false??? I don't think so, hence you > conclusion is not correct. > > > > > I consider this to be inconsistant behavior in DBISAM > > Yes I am sure, I just checked it, here were the results, using DBISAM 4.25 Build2. I created a small app to test this, I added a button to my form then when I click it opens the table show the readonly property status then closed the table Here are the results Set the tablename.dat to be readonly click the button readonly property is true (which is correct) Now I DO NOT restart the program Set the tablename.dat to NOT be readonly click the button readonly property is still true (which is incorrect) Now I restart the application Set the tablename.dat to NOT be readonly click the button readonly property is false (which is correct) Now I DO NOT restart the program Set the tablename.dat to be readonly click the button readonly property is changed to true (which it is, but notice it automatically changed from false to true) Now I DO NOT restart the program set the tablename.dat to NOT be readonly only click the button the readonly property is still set to true (which is incorrect) Notice the inconsistancy? DBISAM automatically changes the readonly property to true when the file is readonly but it does not automatically change it back to false when the file is not readonly. Bern-- |
Mon, Jan 15 2007 6:42 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Bern,
<< Set the tablename.dat to be readonly click the button readonly property is true (which is correct) Now I DO NOT restart the program Set the tablename.dat to NOT be readonly click the button readonly property is still true (which is incorrect) >> Actually, this is correct. The default state of the ReadOnly property is False. Therefore, if you didn't restart the application and left the ReadOnly property as True, then DBISAM will not touch it if the underlying table is R/W. In such a case, DBISAM assumes that you simply want to open the table using a read-only table cursor since ReadOnly=True. IOW, it doesn't keep track of who or what set ReadOnly:=True, it simply just uses the current value of the property. << Now I restart the application Set the tablename.dat to NOT be readonly click the button readonly property is false (which is correct) Now I DO NOT restart the program Set the tablename.dat to be readonly click the button readonly property is changed to true (which it is, but notice it automatically changed from false to true) Now I DO NOT restart the program set the tablename.dat to NOT be readonly only click the button the readonly property is still set to true (which is incorrect) >> Again, the ReadOnly property is a developer-controlled property. It is not up to DBISAM to change it *except* in the case where DBISAM *knows* that it cannot possibly give the developer a non-read-only table cursor when opening a table marked as read-only at the OS level. This is done to avoid having a situation where the user/developers is allowed to update records using the table component only to get a DBISAM engine error when they Post because the underlying table is read-only. << Notice the inconsistancy? DBISAM automatically changes the readonly property to true when the file is readonly but it does not automatically change it back to false when the file is not readonly. >> See above. The inconsistency is entirely on purpose. -- Tim Young Elevate Software www.elevatesoft.com |
Mon, Jan 15 2007 7:41 AM | Permanent Link |
"Bern Rudisill" | Tim Young [Elevate Software] wrote:
> Bern, > > << Set the tablename.dat to be readonly click the button readonly > property is true (which is correct) Now I DO NOT restart the program > Set the tablename.dat to NOT be readonly click the button readonly > property is still true (which is incorrect) >> > > Actually, this is correct. The default state of the ReadOnly > property is False. Therefore, if you didn't restart the application > and left the ReadOnly property as True, then DBISAM will not touch it > if the underlying table is R/W. In such a case, DBISAM assumes that > you simply want to open the table using a read-only table cursor > since ReadOnly=True. IOW, it doesn't keep track of who or what set > ReadOnly:=True, it simply just uses the current value of the property. > > << Now I restart the application > Set the tablename.dat to NOT be readonly click the button readonly > property is false (which is correct) Now I DO NOT restart the program > Set the tablename.dat to be readonly click the button readonly > property is changed to true (which it is, but notice it automatically > changed from false to true) Now I DO NOT restart the program > set the tablename.dat to NOT be readonly only click the button the > readonly property is still set to true (which is incorrect) >> > > Again, the ReadOnly property is a developer-controlled property. It > is not up to DBISAM to change it except in the case where DBISAM > knows that it cannot possibly give the developer a non-read-only > table cursor when opening a table marked as read-only at the OS > level. This is done to avoid having a situation where the > user/developers is allowed to update records using the table > component only to get a DBISAM engine error when they Post because > the underlying table is read-only. > > << Notice the inconsistancy? DBISAM automatically changes the > readonly property to true when the file is readonly but it does not > automatically change it back to false when the file is not readonly. > >> > > See above. The inconsistency is entirely on purpose. Then basically if I allow the end user to change folders to open tables then I as the programmer really have no way of know if the table is actually read/write once the readonly property is set to true (either via DBISAM because of a read only table, or if I set it manualy). So in this case everytime they choose a table and I open it I will have to write other code to see if the table is readonly or not and if it is not then set the readonly attribute back to false. Bern -- |
Mon, Jan 15 2007 9:56 AM | Permanent Link |
"Robert" | "Bern Rudisill" <bernr@no-sp.am.exitcare dot com> wrote in message news:2A6A7D6A-C57F-47C0-8924-7098AE1E2F99@news.elevatesoft.com... > > Then basically if I allow the end user to change folders to open tables > then I as the programmer really have no way of know if the table is > actually read/write once the readonly property is set to true (either > via DBISAM because of a read only table, or if I set it manualy). So in > this case everytime they choose a table and I open it I will have to > write other code to see if the table is readonly or not and if it is > not then set the readonly attribute back to false. Please. You are trying to use the property for two things: 1. To set a table to read only and 2. To inquire if the table physical media is read only. It is impossible to do that automatically in every case using just one property. As Tim explained there is no way for the engine to know if a table's readonly := true was set by the engine because you attempted to open a table on a CD, or if was set by the application's logic. Therefore, DBISAM has to respect the setting of true, and not change it even though the physical media allows for read write. If you want to know if the DATABASE is read only, simply set the propety to false, and open the table. If DBISAM changed it to true, bingo, it is read only. Robert |
Tue, Jan 16 2007 8:52 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Bern,
<< Then basically if I allow the end user to change folders to open tables then I as the programmer really have no way of know if the table is actually read/write once the readonly property is set to true (either via DBISAM because of a read only table, or if I set it manualy). So in this case everytime they choose a table and I open it I will have to write other code to see if the table is readonly or not and if it is not then set the readonly attribute back to false. >> If you're going to allow users to switch back and forth between databases that may have read-only table files in them and databases that may not, then yes, you're going to have to go one step further to ensure that after switching databases, but before the TDBISAMTable components are opened, any TDBISAMTable components have their ReadOnly properties set to False. -- Tim Young Elevate Software www.elevatesoft.com |
Thu, Jan 18 2007 7:53 AM | Permanent Link |
Chris Erdal | "Bern Rudisill" <bernr@no-sp.am.exitcare dot com> wrote in news:2A6A7D6A-
C57F-47C0-8924-7098AE1E2F99@news.elevatesoft.com: > Then basically if I allow the end user to change folders to open tables > then I as the programmer really have no way of know if the table is > actually read/write once the readonly property is set to true (either > via DBISAM because of a read only table, or if I set it manualy). So in > this case everytime they choose a table and I open it I will have to > write other code to see if the table is readonly or not and if it is > not then set the readonly attribute back to false. > This is a very special case, Bern, because your application allows similar access to updatable and non-updatable data in otherwise identical databases. I would definitely NOT want DBISAM to reset ReadOnly to false on updatable tables I opened with ReadOnly set to True in the IDE. So you've got to use a strategy of your own to distinguish between Readonly / ReadWrite databases before you try to use them. IMHO the simplest way is to set ReadOnly to false in the BeforeOpen event of EVERY Table (perhaps by inheriting them all from your own version of DBISAMTable), and then choose ONE table that you open in the Database's AfterConnect event to check whether it is writeable. You can then set a global flag (e.g. flag_DBIsReadOnly) so that everything else that accesses the table data knows what to expect. -- Chris (XP-Pro + Delphi 7 Architect + DBISAM 4.24 Build 1) |
« Previous Page | Page 2 of 2 | |
Jump to Page: 1 2 |
This web page was last updated on Friday, March 29, 2024 at 03:30 AM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |