Default open_mode for table.open() if not specified?

[Mike Wilson]

I've hunted the docs and wiki and can't find the answer ( doesn't say ). Most optional components have an explanation what the default is if not specified. I don't see it anywhere. Is there a good resource to read about when/where the different modes should be specified for network environments? Thanks.

[Stan Mathews]

Re: Default open_mode for table.open() if not specified?

No, no such resource. I believe Alpha will in most instances choose the mode least likely to cause a conflict (read/write shared). If you want maximum speed you want read/write exclusive.

I generally use these constructs.

test = table.in_use("customer")
if (.not. test) then
    table.compact(file)
else
    ui_msg_box("Error","File is in use.")
end if

test = table.in_use("customer")
if (.not. test) then
    a_tbl = table.open("customer","FILE_RW_EXCLUSIVE")
else
    a_tbl = table.open("customer","FILE_RW_SHARED")
end if
'do something with table pointer here

[CALocklin]

Re: Default open_mode for table.open() if not specified?

Stan, any particular reason for:
test = table.in_use("customer")
if (.not. test) then

instead of:
if .not. table.in_use("customer") then

I ask because, although I can't guarantee they are still issues today, I've seen situations in previous versions where "combining" doesn't work and I'm wondering if you've seen a problem with this one.

FWIW, I've seen problems with the following in the past and continue to use my "proven solution" today just in case.

IF table.current().MyField = <some value>
(or table.current().mode_get(), etc.)
worked most of the time but not all the time.

However, this worked ALL the time:
tc = table.current()
IF tc.MyField = <some value>

I know I've seen one or two others similar to the above but can't recall them right now. They may have even required other specific situations to see the problem and, therefore, I haven't seen them repeated.

This one is a bit different. Again, this construction worked most of the time but sometimes gave a "table not found" error:
lookupc( "F", Cust_idv, "Cust_Namef", "Customers", "Cust_id_" )
while this worked perfectly every time:
lookupc( "F", Cust_idv, "Cust_Namef", a5.Get_Path()+"\Customers.dbf", "Cust_id_" )

[Mike Wilson]

Re: Default open_mode for table.open() if not specified?

Thanks Stan and Cal,
Good information. I guess my question is, what is the need/what should you use to avoid conflicts. Of course exclusive access will eliminate conflicts but that means 2 views to the table are denied and that is in itself a conflict. So I'm trying to wrap my head around the situations that require one mode of access or another.

[martinwcole]

Re: Default open_mode for table.open() if not specified?

What I do, where I want to restrict the user to read/only is to set the form to read only
When they introduced the new "parentformmodal," I had a lot of trouble with it. So all forms, (especially based on a set,) are set to modeless, but at the onfetch event, I use parentform.allow_change(.f.) and they have to use an edit button on the form - this works.

You can put code in an edit button, that under certain circumstances will prevent the user from editing.

[Stan Mathews]

Re: Default open_mode for table.open() if not specified?

any particular reason for:
test = table.in_use("customer")
if (.not. test) then

Not really. That was the way I learned it in the docs and just stuck with it.

[Al Buchholz]

Re: Default open_mode for table.open() if not specified?

any particular reason for:
test = table.in_use("customer")
if (.not. test) then

Not really. That was the way I learned it in the docs and just stuck with it.

I think it is easier to debug when the steps are smaller.

Instead of wondering why the if fails, you can see the result in the variable.

[CALocklin]

Re: Default open_mode for table.open() if not specified?

I think it is easier to debug when the steps are smaller.

Instead of wondering why the if fails, you can see the result in the variable.

I agree. I just wondered if he'd seen a problem with the other format.

(Although I have used one or two really complex expressions that could be broken into smaller parts but weren't because they are in a loop where speed was an issue. I think in one of those cases it was so complex that I included the broken down code in a series of comment lines so I could figure it out in the future if necessary!)

[Ray in Capetown]

Re: Default open_mode for table.open() if not specified?

You can put code in an edit button, that under certain circumstances will prevent the user from editing.

And the F3 button? how to deal with that?
I just started to use the Can Edit event. Not the tidiest.

[Finian Lennon]

Re: Default open_mode for table.open() if not specified?

FWIW, I'm 99.9% sure that the documentation, though it doesn't now, used to state that, if no open mode was specified when using table.open(), the default open mode was FILE_RW_SHARED. As a result I've rarely specified the open mode unless I want to open the table in exclusive mode.

[Mike Wilson]

Re: Default open_mode for table.open() if not specified?

FWIW, I'm 99.9% sure that the documentation, though it doesn't now, used to state that, if no open mode was specified when using table.open(), the default open mode was FILE_RW_SHARED. As a result I've rarely specified the open mode unless I want to open the table in exclusive mode.

Finian,
That is what I have been doing based upon the ASSUMPTION of that, but never tested it. I am working on testing the gamout and documenting the situations and errors. Will post when complete.

[Mike Wilson]

Re: Default open_mode for table.open() if not specified?

I came back to this thread because I remember testing the "gamout" and posting the results ("I am sure I did ). Where oh where??.....