Fun FoxPro Quirk using NOUPDATE and AGAIN together

[Joe Crescenzi]

Here's something fun that I stumbled into that I decided was worthy of sharing for those who may be curious.

When you open a table using USE... NOUPDATE, any subsequent USE commands with AGAIN and ALIAS may, or may not end up inheriting the Read Only / NOUPDATE status, depending on how the first USE command was called.

Here's an example.

CLOSE DATABASES
USE testtable IN 0 AGAIN SHARED ALIAS "Regular" 
USE testtable IN 0 AGAIN SHARED ALIAS "ReadOnlyVersion" NOUPDATE
USE testtable IN 0 AGAIN SHARED ALIAS "Regular2" 
USE testtable IN 0 AGAIN SHARED ALIAS "Regular3"

The result here will be that you will have four open tables, with the one called "ReadOnlyVersion" being the only one that is open in Read Only mode.

Select area:  4, Table in Use: C:\SOURCECODE\CARTPRO.NEW\TESTTABLE.DBF    Alias: REGULAR3
Select area:  3, Table in Use: C:\SOURCECODE\CARTPRO.NEW\TESTTABLE.DBF    Alias: REGULAR2
Select area:  2, Table in Use: C:\SOURCECODE\CARTPRO.NEW\TESTTABLE.DBF     (Readonly) Alias: READONLYVERSION
Currently Selected Table:
Select area:  1, Table in Use: C:\SOURCECODE\CARTPRO.NEW\TESTTABLE.DBF    Alias: REGULAR

However, if you open the tables with the NOUPDATE line first, ALL of the tables will end up Read Only.

CLOSE DATABASES
USE testtable IN 0 AGAIN SHARED ALIAS "ReadOnlyVersion" NOUPDATE
USE testtable IN 0 AGAIN SHARED ALIAS "Regular" 
USE testtable IN 0 AGAIN SHARED ALIAS "Regular2"
USE testtable IN 0 AGAIN SHARED ALIAS "Regular3"

Here's the result.

Select area:  4, Table in Use: C:\SOURCECODE\CARTPRO.NEW\TESTTABLE.DBF     (Readonly) Alias: REGULAR3
Select area:  3, Table in Use: C:\SOURCECODE\CARTPRO.NEW\TESTTABLE.DBF     (Readonly) Alias: REGULAR2
Select area:  2, Table in Use: C:\SOURCECODE\CARTPRO.NEW\TESTTABLE.DBF     (Readonly) Alias: REGULAR
Currently Selected Table:
Select area:  1, Table in Use: C:\SOURCECODE\CARTPRO.NEW\TESTTABLE.DBF     (Readonly) Alias: READONLYVERSION

I discovered this accidentally when I decided to open some tables in NOUPDATE on a screen that didn't allow editing, then without realizing that later in the session I open another form that DOES allow edits, and since the previous table was already open in ReadOnly, the second form didn't allow edits.

 

[EinTerraner]

Look at the Fox-Helpfile
When you open a table again in another work area, the table in the new work area takes on the attributes of the table in the original work area. For example, if a table is opened for read-only or exclusive access and is opened again in another work area, the table is opened for read-only or exclusive access in the new work area.

 

[Joe Crescenzi]

I definitely expected the exclusive option to play a major role, after all you can't have one version that's exclusive and allow work area to be able to open it, but the NOUPDATE was a bit more of a surprise because it does allow other work areas to be completely independent when the initial version was not opened with NOUPDATE.

So, if you open the table normally, you can re-use it as often as you want, sometimes with NOUPDATE, sometimes without it, and each work area will have whatever you specify to decide whether it's read only or not. However, if the first version of the USE has the NOUPDATE, you no longer have a choice. All will be read only.

There's no workaround other than not opening a table using NOUPDATE if you think you may need to re-open that table elsewhere. You'd think they would have a reciprocal UPDATE option so you can implicitly declare whether to allow or not allow edits, just like there's a SHARED and EXCLUSIVE option.

Anyhow, I stumbled on this accidentally and thought it could be helpful in case somebody searches for it some day.