Icon View Thread

The following is the text of the current message along with any replies.
Messages 11 to 18 of 18 total
Thread Problem changing DatabaseName property
Sat, Jan 13 2007 12:39 PMPermanent 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 PMPermanent 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 PMPermanent 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 AMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email 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 AMPermanent 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 AMPermanent 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 AMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email 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 AMPermanent 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 PagePage 2 of 2
Jump to Page:  1 2
Image