Error Message: "...database is in ready only mode..."

Hello Pan X Enthusiasts and Professionals!

When I try and upload a New Generation of my database (“Ledger”) to my server (uploading forms and procedures), I receive the following error message.

image

“p” is one of the fields in my database. Interesting enough, there is no data in any «p» entry.

When I hit “OK”, the database behaves normally, except for the following.

image

The status “Uploading to Server…” does not go away.

When I close the database, I receive the initial message again.

image

After this, when I go to the Server Administration dialog, this database, Ledger is offline.

Also, after this issue, I receive synchronization errors. The errors are never the same either. In other words, the records that have synchronization errors are different each time I attempt to synchronize.

In an attempt to start afresh, I downloaded a copy of this database, from the server, to my local computer. However, the synchronization errors still persist.

Also, I noticed that sometimes, in seemingly random records, long sequences of numbers (1,2,3…899) are pasted into one particular text field named “TYPE”.

This database does not have any features that are different than any of my other shared databases (which are fully operational). The only thing unique to Ledger, is a Payroll program (run on a client computer) that copies entries from our payroll database, to Ledger.

Sorry for the long explanation, but I am having a hard time determining what information is relevant to this problem, and that which is not.

What is the core of the issue I am experiencing here?

Thanks in advance!

Paul

Thank you for the long explanation, I really appreciate it. And the really excellent news is that based on your explanation I was able to duplicate the problem, which is a previously undiscovered bug.

It turns out the problem is due to your use of p as a field name. Some internal Panorama code is using p as a local variable, and when that internal code tries to modify the local variable, Panorama is thinking that the code is trying to modify the field. At this point I am not sure why, there is code in place that is supposed to recognize that a variable is in play. The problem is not obvious, so more research will be needed to track this down. I was able to duplicate the error with a simple 3 line program.

For now, you’ll have to change the name of the p field to something else. In fact, I would probably avoid use of any single character lower case letter as a field name.

I think this is probably completely unrelated.

I believe at one time @RAmeeti reported a similar symptom. Robert, does this ring a bell?

Update: I have fixed the problem that was causing the “read only mode” error when uploading a new generation. Two parameters to an Objective-C subroutine were reversed. :face_with_symbols_over_mouth:

Until the fix is released, please rename your field as I mentioned in the previous post.

2 Likes

I believe that it may be found that the sequence of numbers are the ServerRecordID of the active records when the (a) bug rears its head. I’m not remembering much more than that at the moment. I believe the field is not significant but is merely the active field at that moment in time (of the procedure that is running.)

BTW, Jim, Did you note the ‘ready only mode’ error message?

Thank you for your speedy help! Field «p» is now renamed, and Ledger is working well.

Thank you for the information. I will investigate this further.

The sequencing issue seems to occur when this shared database is opened. There is no .Initialize program on the database in question.

Also, no procedures use the ServerRecordID function. The closest function I use is “sequence”. However, the issue does not show up after this function is executed.

Today, I noticed that this database does not have a Record ID field. I created a Record ID field, and put a “+” in the field property “Default Value”, and then uploaded this new field arrangement to the server. So far, no mystery number sequences have appeared.

The ServerRecordID is typically transparent to the user and is assigned and used internally by the server. A user can determine what any particular record’s ServerRecordID is by using info("ServerRecordID). It just happened that I was intrigued by the appearance of a series of numbers that got smashed into a field of mine, and it turned out that the odd series of numbers was the serverRecordID of the current selection of records when the bug caused the inappropriate write to my table. (This is my best recollection of the situation.)

I assume this means it hasn’t happened in a long time, which I’m glad to hear.

It hasn’t happened because I have commented out the code that causes the crash. I am not accomplishing a task that I’d like to do but can not do successfully. If I write to field following a SendEmail task, the error happens most of the time. It is probably one of those situations that seems to come up more often with Pano X that is often worked around by using a Wait.

I am still experiencing the improper writing of long number sequences. This only happens on one of my databases. See below for a screen shot.

Screen Shot 2022-10-21 at 3.33.01 PM

In this case, the exact number sequence is as follows:

8,10,13,16,17,22,24,26,33

This sequence of numbers does not seem to correspond to any sequence of numbers, or sequence of records, in this database. At other times, this sequence of numbers is different than that above. The sequence of numbers only copies to my field named “Status”.

The copying of number sequences seems to happen when this database is opened. This database does not have a .Initialize procedure.

Also, in case it matters, the primary form in this database, uses a text list.

This database contains a program that uses the sequence function. This is the only function I can think of that uses a sequence of numbers.

Do you have any thoughts on what might be happening here?

I am going to bet that this is a relatively small database (in record count), and that it is shared.
If you use Morph Field, and use some scrap field with the formula Info(“ServerRecordID”), you will find that those numbers are equivalent to the ID’s of certain records that you might recall were at one time selected for use for some action. Further, they may have been selected when Panorama crashed. This does not have anything to do with the Sequence function.

Revisiting this topic, I can reliably recreate this issue on one by running the procedure below.

This procedure only triggers long number sequences when I have a particular form open. This form contains two tiles, set to the view-as-list format. The long number sequences are serial numbers from multiple records in one field, and then they are pasted into a second field.

Here is the aforementioned procedure:

local iwindow,iSelected,iSizer,iPitch,iLoop,iRollers,iSpirals,iClearance,iTurns

iwindow=info(“windowName”)
iSpirals=“yesorno”

Save
hide

select emptycell(“ShipDate”)=true()
Field Priority
SortUp
FirstRecord
iSelected=info(“selected”)

GoForm “Sizers on Order (Print)”

// Check for Spirals Database //

if info(“files”) notcontains “Spirals”
openfile “Spirals”
window “Work Orders:Sizers on Order (Print)”
iSpirals=“No”
endif

field Turns
formulafill lookup(“Spirals”,“Name”,striptoalpha(«Spiral»),“Turns”,“”)
firstrecord

// Start of Loop //

for iloop,1,iSelected

// Definitions //

if («Sizer» contains “S”) and («Sizer» notcontains “M”) and («Sizer» notcontains “L”) and («Sizer» notcontains “X”) and («Sizer» notcontains “T”)
iSizer=“S”
endif

if («Sizer» contains “M”)
iSizer=“M”
endif

if («Sizer» contains “L”)
iSizer=“L”
endif

if («Sizer» contains “X”)
iSizer=“X”
endif

if («Sizer» contains “T”)
iSizer=“T”
endif

if «Spiral» contains “-4-”
iPitch=“4”
endif

if «Spiral» contains “-6-”
iPitch=“6”
endif

if «Spiral» contains “-8-”
iPitch=“8”
endif

if «Spiral» contains “-10-”
iPitch=“10”
endif

iClearance=0

if («Special» contains “clearance”) and (iPitch=“4”)
iClearance=2
endif

if («Special» contains “clearance”) and (iPitch=“6”)
iClearance=1
endif

if («Special» contains “clearance”) and (iPitch=“8”)
iClearance=1
endif

if («Special» contains “clearance”) and (iPitch=“10”)
iClearance=1
endif

iTurns=0
iTurns=«Turns»

if iSizer=“S” and iPitch=“4” and iTurns≠0
«Turns»=(simple formula)
endif

if iSizer=“S” and iPitch=“6” and iTurns≠0
«Turns»=(simple formula)
endif

if iSizer=“S” and iPitch=“8” and iTurns≠0
«Turns»=(simple formula)
endif

if iSizer=“M” and iPitch=“4” and iTurns≠0
«Turns»=(simple formula)
endif

if iSizer=“M” and iPitch=“6” and iTurns≠0
«Turns»=(simple formula)
endif

if iSizer=“M” and iPitch=“8” and iTurns≠0
«Turns»=(simple formula)
endif

if iSizer=“L” and iPitch=“4” and iTurns≠0
«Turns»=(simple formula)
endif

if iSizer=“L” and iPitch=“6” and iTurns≠0
«Turns»=(simple formula)
endif

if iSizer=“L” and iPitch=“8” and iTurns≠0
«Turns»=(simple formula)
endif

if iSizer=“X” and iPitch=“4” and iTurns≠0
«Turns»=(simple formula)
endif

if iSizer=“X” and iPitch=“6” and iTurns≠0
«Turns»=(simple formula)
endif

if iSizer=“X” and iPitch=“8” and iTurns≠0
«Turns»=(simple formula)
endif

if iSizer=“T” and iPitch=“6” and iTurns≠0
«Turns»=(simple formula)
endif

if iSizer=“T” and iPitch=“8” and iTurns≠0
«Turns»=(simple formula)
endif

if iSizer=“L” and iPitch=“10” and iTurns≠0
«Turns»=(simple formula)
endif

if iSizer=“X” and iPitch=“10” and iTurns≠0
«Turns»=(simple formula)
endif

downrecord

endloop

window “Work Orders:Sizers on Order (Print)”

printtopdf “”,“Printer”,“”,“orientation”,“portrait”

if iSpirals=“No”
window “Spirals:Spiral Description”
closefile
endif

window “Work Orders:Sizers on Order (Print)”
goform “Sizers on Order”

if info(“windows”) notcontains “Production Specifications”
openform “Production Specifications”
endif


Also, I have tried quitting the database in question, and restarting. But, this does not solve the issue.

There is a longstanding known bug when using the downrecord statement when a view-as-list form is open (even if the view-as-list form is not the topmost window). You should make sure the veiw-as-list form is closed for this portion of the code.

Thank you. I edited the procedure to ensure that all view-as-list forms are closed when down record executes.

Unfortunately, long number sequences still overwriting some of my fields.