I’ve found a Server Error log which runs only on the server and tells me when a file can not be taken offline etc.
I’ve found an Instrumentation Error log which is handy if I’ve turned on Instrumentation but seems to be for very low level crash stuff.
I’m looking for a log that would log my ‘Can not lock record’, ‘Can not commit’, ‘Server unavailable’, kind of errors that are happening during beta. Are these Notification errors easily loggable? Perhaps through Instrumentation? If so, how? I’d like to see the frequency of these things and also be able to make a note when they happen.
You mean something like this?
It’s in the Preferences under the Server tab
Ok. Ya those. So I was looking in the right place. But I was deceived. Here it is Sat, the 6th, and yet when I poked at the popdown, it only offered me last Tuesdays, the 2nd.
If I chose to reveal in Finder, then I saw the more recent files with more entries that did include my ‘Commit Error’ issues. (Tuesday must have been a slow day.)
Wonder why it got stuck on only offering me files from 4 days ago.
Having found those more recent error logs with the Can not Commit issues, Record does not exist issues, etc., I am now prompted to suggest that the error log include the db file name when a record is not locked and in similar situations. As this type of error might be happening in real situations like where Cooper actually has multiple users and a record lock is not necessarily a beta error, I am the sole user of one db where a record lock error should not be happening. I also though have some db files where multiple people are potentially using them and I too could have acceptable errors on those dbs. Thus the name of the db that is having errors is important to know for debug purposes.
With all of the logging options checked, you certainly get far more info, but with two clients running the same database I can’t tell which is which in the activity.
Unlike Pan6 Enterprise, errors seem to be solely logged separately. I forced a few which did not show in the Sharing Log but were in the Sharing Errors log.
Pan 6 kept a separate Error Log, but with errors also noted along with the rest of the activity it was far easier to monitor the overall performance and to place the errors where they occurred within the server activity.
The Pan6 logs also made it easy to see who was doing what since every login was given a session number that was appended to each log entry.
This is a simple log overall but many times I turned to the logs to track down issues in a larger office situation and the verbosity was a huge help. Sometimes it lead me to a problematic client computer, or showed me that a user kept closing a needed file.
So far I’ve found no way to access the logs via Panorama from other than the server computer. I can access the logs folder all sorts of ways though, in order to review the logs with BBEdit or other app.
1 Like
Agreed. Verbosity allows for filtering as necessary specific to each situation.
And then the ideal of being able to easily import a log file into Panorama to use its filtering. Another item on my To Do List I suppose.
