When server stops, does that get reported?

Panorama X Beta 10.2
1

There are many instances where the server will stop during the running of a procedure. I get an error that the server is not connected, then I remotely connect to the server, start it again, then reattempt to run the macro. Sometimes the server stops again, sometimes not.

When the server does stop due to these bugs when a procedure is running, is this fact uploaded to ProVUE?

Secondly, what does the icon mean that looks like a ‘conversation’ that sometimes appears in the Visible/Total box? When that appears, I have to jump through several hurdles to get the shared icon of the WiFi signal to then reappear.

2

Are you saying that running a procedure on the client causes the server to stop? What do you mean by “stop” – does PanoramaX Server.app crash? The server should never stop no matter what the client does, and there have been no other reports of this that I am aware of. To address this, I would need as exact a description of the steps & code leading to the problem as possible.

That is perfectly normal and it means the current record is locked by this computer. It turns back into the WiFi signal when the record is unlocked.

3

I have reported this many times. And I’ve become so used to it that I’ve taken it for granted and forgot what actually happens so I’ve just now rerun a couple of procedures and did find the 2nd one I chose to crash the server. Repeatedly. And so yes, after the server crashes, when I view the server, I just have to Start the server again to have all ok.
After it crashed minutes ago, I thought ok, let’s try that again. I ran the same procedure and it crashed again. I thought sweet, I’ll forward this db onward. But then I ran that same procedure 5 times again and it failed to crash the server any of those times. Frustrating? Yes. Very.
It works well enough to use if for non critical things but I can not use it for ‘regular’ users as it crashes perhaps once a day regularly.

And I’ll add another comment that is entirely anectdotal so probably has little relevance but it seems very odd.
When a procedure crashes the server, it seems like it will crash the server a 2nd time if repeated. But then, it appears to then no longer crash the server on subsequent runs. (At least for my limited further testing.) So odd that I can’t think this info would be helpful but what the heck, it is what I do believe I see happening.

4

My theory is somewhat standing up for consisitency. I ran a procedure that failed earlier twice crashing the server, then worked several times after that.

I felt lucky so I ran the procedure again just now. It crashed the server. Aha! Let me try my theory. I started a movie with the local client error on screen. I moved to the server and it was not running. I quit my local copies, restarted the server, opened my local copies, reran the procedure and since it was the 2nd time, it did crash the server! I repeated the process and it did not crash the server the 3rd time. And a movie documents the crash during a procedure the 2nd time but not the 3rd time.

5

And there’s more.
Running a procedure this time crashed Panorama locally. The server did not crash. I started the movie with the crash scren from the local crash. I then restarted Panorama, reran the procedure, and the server crashed. Restarted the server, quit and restarted the local copies, reran the procedure and it ran without anything crashing. And again without any problem. Having Panorama crash locally is not common. Only twice today, hours apart. Most always it is just the server that crashes. These are on 2 different computers, a server computer, and a local computer.

Do I have consistency, not really. But give me 15 minutes of running procedures and I’ll bet that I can get it to crash.

6

I wrote a separate post partly in response to this thread. I made it a new thread to make it easier to find in the future.

Am I saying your server is not crashing? No, of course I’m not saying that.

However, the server is not running the procedure. It is not even aware that a procedure is running. As described in the post, the server is just running a very limited repertoire of operations over and over again. Mostly just lock and commit.

Perhaps there is some sort of timing issue where running a bunch of operations in a row quickly is causing a crash? That should not happen – the server is designed to process each request sequentially, finishing each one before it moves on to the next. But that would seem to possibly fit the description of the problem you are having. Though is anyone else using the server while you are? It sounds like you haven’t deployed to other users yet. If it’s only you, I would think that would automatically rule out a timing issue, since if there is only one client running it is automatically going to wait for a response from the server before issuing another request to the server.

Since you are able to run the problem procedure most of the time, that means that you should be able to turn on logging on the server, run the procedure, and get a record of what server operations are being performed. Perhaps that would provide a clue as to what is going on. And if you have logging on when it crashes, it should be possible to see what step it was getting to at the point of the crash.

Beyond the logging in the Preferences panel, all of the sharing code has instrumentation built into it. You can enable that and then we’ll have an exact log of what was happening on the server right before the crash. I think maybe you missed the instrumentation sessions, which were the first ones I did. If so, please go back and watch that. There is no point in guessing when the system can generate tons of information. Perhaps it won’t pinpoint the problem, but if not I can add additional instrumentation where needed in the next release.

8

On the server, in the Panorama Preferences, I used the Logging tab and clicked the 'Add, Modify, & Delete Records checkbox and also the Bulk Data Modifications checkbox.

I then ran 2 procedures and the 2nd one crashed the server. Now what? Where are the logs kept and what should I do with them?

If you want me to crash the serve with certain instrumentation triggered, you’ll have to let me know specifically what may be helful as I haven’t a clue. I’m gunna use the ‘getting old’ excuse for not being as sharp as I once was.

9

I guess now I have to not only write the documentation, I have to read it also? :sleepy:

This link will enable instrumentation of the fill code on the server.

panoramax://zlog?_EnterpriseServerLib=_serverFILLCOLUMN,_serverFORMULAFILL,_serverPREFILLCOLUMN&Objective-C%20Classes=FillSyncStatement

You need to use this on the copy of Panorama on the server machine.

Before attempting to use this link, you’ll need to enable instrumentation on this computer. Please either watch the Instrumentation course or read the Instrumentation help page, or both.

How big is this database? How many records are you filling? Of course it should never crash, but you also have to be much more judicious in using fill in a shared database, it’s generally not a good idea to fill every record as you might in a single user database. I discussed this in detail in the Panorama X Server Deep Dive Part 5 video.

10

As you know, I read 2,257 pages of the documentation. Very closely. While I did read that page on Feb 6 of this year, my memory failed me and I did not remember that that page existed. I erroneously thought it was not documented. My error.

From the Daily Activity Sharing Log…

|08/14/2021|8:16:27 pm|Session 1 (Robert 16 MacBook Pro:RAmeeti) modified 0 of 1233 records in field ScrapText of database: Oasis Sailing Club Calendar (ts:604)|
|---|---|---|
|08/14/2021|8:16:29 pm|Session 1 (Robert 16 MacBook Pro:RAmeeti) modified 0 of 1233 records in field Skipper1 of database: Oasis Sailing Club Calendar (ts:605)|

What does a Green icon mean vs a Red icon?

I am trying to FormulaFill 623 records, Propagate 827 records, with a database of 1233 records.

One of the procedures that crashes the server (not always) is the following code:

Global GHeaderMonthAsOf

RemoveAllSummaries

// Select 12 months up to last full month prior

GHeaderMonthAsOf = "Skipper 9 in 12 as of " + DatePattern(MonthMath(Month1st(today()),-1),"Month YYYY")

// Message LHeaderMonthAsOf

Select «Sail_Dt» >= MonthMath(Month1st(today()),-12) And «Sail_Dt» < Month1st(today()) And «Depart» <> "" And «Boat» NotContains "-A" And «Boat» NotContains "-T" And «Boat» NotContains "-M" And Skipper1 ≠ "Club Event"

Field ScrapText
FormulaFill LastWord(Skipper1)+", "+FirstWord(Skipper1)
RunModifyFill
GroupUp
Field «Sail_Dt»
GroupUp by Month
Field Return
Count
Field Skipper1
Propagate
Field Boat

OutlineLevel 1

OpenForm "9 in 12"
PrintPreview
11

The red icon is for error logs. One always hopes that those are empty.

The green and purple icons are for normal activity logs.

I’ll bet that wasn’t the first time you ran this procedure since opening the database.

When you do a fill operation on a shared database, Panorama first does the fill on the local data. As it does so, it checks to see if the data actually changed. Only changed data is sent to the server.

Your procedure does two fill operations. The first is:

Field ScrapText
FormulaFill LastWord(Skipper1)+", "+FirstWord(Skipper1)

Your log says:

modified 0 of 1233 records in field ScrapText of database

So I think the procedure had been run before, and the ScrapText field already contained the data. So the server did nothing.

Your next line is:

RunModifyFill

Does your database include a .ModifyFill procedure? If it does, then we need to know what is in it. I’m thinking there isn’t one since the server doesn’t seem to show any activity generated by that.

Your second fill is:

Field Skipper1
Propagate

For this, the log shows:

modified 0 of 1233 records in field Skipper1 of database

Again, no records modified. I think this is because you don’t have any empty Skipper1 cells in your database.

Now in this case, some records were definitely modified by the propagate. But they were all summary records. Summary records don’t exist on the server, so they don’t count as far as shared fills go.

I can see that the purpose of this procedure is to prepare the database for printing. You don’t actually want to keep any of the changes made by this procedure, you just want to print them. You need the scrap field so you can group by it.

Panorama actually has a feature to facilitate temporary database changes like this – the serverupdate statement. This is not new to Panorama X, in fact I think it might even have been included in Panorama 3 when using Butler servers. In the current documentation it has it’s own help page, and this is also discussed in the * Record Locking in Procedure Code* help page under the heading Temporarily Disabling Record Locking (and Server Updates). There’s an example shown that is very similar to what you are doing.

You should modify your code by putting this at the top:

serverupdate "off"

and this at the bottom:

serverupdate "on"

This essentially makes the database temporarily single user. Data changes made in this mode will not be kept permanently.

I think making this change will immediately fix your crashing problem. However, that still leaves a crashing problem for me. I suspect the problem is probably related to the state of the data. For example, if the ScrapText field was empty, then the server would have 1233 changes to process. That shouldn’t be a problem, but maybe it is. This probably why it crashes sometimes but not other times – it depends on the current state of the database. Does that ring any bells for you? Perhaps with this additional knowledge you could play with it a bit more and perhaps see a pattern.

12

Was it the first time I ran this code since opening the database? Likely not as I am trying to see a pattern. It may well not have crashed the first time so I rerun it again and again until it crashes again hoping to see some pattern.

No .ModifyFill. But there is a .Modify.

There will not be any empty Skipper1 records except for the just created GroupUp Summary records. The Propagate is to get that info into the Summary records.

I am aware of the ServerUpdate statement and I do know that that will likely make my problem go away. It will not fix anything. But I am the stubborn type who feels if I am going to be a beta tester, my job is not to learn how to avoid the bugs, but rather to find them and eliminate them. After the program is released, or perhaps tomorrow, I may in fact want to use these same legitimate commands and not for printing. I would not have done myself, nor anyone else, a favor by avoiding a bug. Better to squash a significant bug now before the version is released.

I’m not seeing the ‘state’ of the db to be mattering. After a crash and a restart of Panorama, just running the same procedure, or perhaps a very similar procedure a few times will result in the crash. I can do nothing but a start of the db, and a few times running of these procedures, and the crashes will occur.