Panorama X file corruption

Great info. However, because of the usefulness of such a date/time pattern function which always delivers a chronologically sound date/time stamp (with descending unit values each with leading zeros to force two characters), I think that two simpler specialized functions, such as “isodatepattern(datevariable)” and “isosuperdatetimepattern(superdatevariable)” would be extremely useful. No need to fuss with date/time patterns at all!

Furthermore, the default date input format “MM/DD/YY” in the data sheet should be “YYYY/MM/DD” which would sort correctly whether or not it was formatted as a date or a text data type. Just my opinion to make coding simpler. Thanks for the feedback.

Not quite what you are asking for (doesn’t use the exact ISO format) but Panorama does have a timestampstr( function that I have frequently used for naming files chronologically.

You can use text funnels if you don’t want the time, or only want accuracy down to minutes or seconds.

This is almost what I wished for, except that there is no way to input an arbitrary date/time argument. There are occasions when the date/time of interest may not be “now()” but the date/time of another instant, e.g. past generation of pay slip, invoice, etc.

However, I do like the output format that you have chosen.

I guess one will have to use Dave’s solution … Thanks Dave … which requires only two arguments or define an new function with a one “superdate” argument.

I’d like to report a similar situation of apparent file corruption.
After a break in trying to work on Panorama X because it was all seeming too hard, and I didn’t have enough time, I was spurred into action by messages on my computer saying Panorama 6 wasn’t optimised for the current system, and the developer would have to fix it. Knowing that the developer isn’t planning on doing that, I was panicked back into action.
To my delight, everything was working really smoothly. I was having relatively few crashes (none at all for quite a while), buttons seemed to be doing what they should, and I was getting the programme into relatively good working shape. Then suddenly, everything went crazy. The programme (it runs as 4 separate databases inter-relating) wouldn’t open the other programmes up. The buttons weren’t triggering the programme sequences they were meant to, and even going into the programme and pressing “run” wasn’t doing anything.
I’ve tried re-installing Panorama X, shutting down the computer and letting it sleep on things, and still no change. Sometimes I can open the files from “Find and Open”, and sometimes I can’t (I’d never had to use this option at all previously, but read about it in a different thread about opening databases).
Having read this thread, I’ve opened another database I’d been working on, and it seems to be operating normally, so I guess it is these files rather than the programme. Very devastating. I have no idea where to start to try to get it working again??

I have to point out that I see this entirely differently. I have done nothing BUT plan for this contingency for over six years. Plan, and then code and code and code, hundreds of late nights and weekends. Ensuring that Panorama would continue to work when Apple dropped the Carbon APIs and 32 bit support was the entire point of Panorama X.

Unfortunately I don’t have any immediate suggestions based on the description you have given.

I want to make a general comment on this topic, to try to set a context from my point of view.

Over the past year, Panorama X usage has been steadily growing. It’s now over 5,000 hours per month. In the early beta days (3 years ago), usage was definitely higher on the weekend and lower during the week. I interpreted that as people “playing” with Panorama X rather than seriously using it for work. However, about 18 months ago a crossover point was reached, and now usage is significantly stronger during Monday thru Friday, with a definite dip on the weekend. So I believe that a majority of Panorama X users are using the software as a business tool for production use. Which is good – that’s what it’s for.

I’m bringing this up to give context to reports of problems. Certainly there are problems, and unfortunately there will always be problems in a system with hundreds of thousands of lines of code that runs on an ever changing operating system with hundreds of millions of lines of code. But as far as I can see, Panorama X is running fairly smoothly on a daily basis for the vast majority of users.

I certainly take reports of problems to heart. I want Panorama to work perfectly all the time for every user, it makes me feel kind of sick to read reports like those from Dominique and Michelle. However, I look around and see similar reports for all kinds of software, including and especially Apple system software, so I know I’m in good company in not being able to solve every mysterious problem immediately, or sometimes ever. So I keep chipping away, and keep my eye on the big picture which gives me encouragement that at least I am hopefully on the right path.

2 Likes

I guess if your problem is that you created a programme that was so good, that when it gets too old we’re struggling to replace it, that’s a relatively good problem. Don’t lose too much sleep about it, and keep working towards the goal of creating a replacement that’s just as good.

In the meantime, I guess the solace I drew from your reply is that you are not hearing multiple similar problems occurring everywhere. That gives me the courage to re-convert the original Panorama 6 database and start again. Fingers crossed.

I have a clue re my problem.

The crashes and malfunctions appear to be related to the addition of a text list to the database. It was a single column, no duplicates, database navigator, list.

I discovered this because I made a new version of my database from the Pan6 version. I deleted all forms and all programmes, stripping it down to raw data. Then I started adding forms back in. I’d come up with the idea of using one of these lists on a form, to save me creating an extra form. When I created it, the programme immediately crashed. Although it hadn’t been the last thing I’d done with my other database, I thought, in retrospect, that was probably when the crashes started occurring, (ultimately progressing to complete non functioning of the database). I managed to open my old corrupted database, deleted the 2 lists I had put in, and it started working normally again.

I have used similar lists elsewhere - but probably also with frequent crashes - and never got into this much trouble with it. However, the fact that it happened in both versions of the database makes me feel it is an internal error.

Hope this information helps you sort it out. I’ll play a bit more - probably try to get the list working with a variable rather than navigation, and keep you posted on what works/doesn’t, and keep you posted.

1 Like

Thanks for this sequence, which I’ve incorporated into my Initialize procedure (without fully analysing how you’ve done it). Is it possible to make a ‘ding’ noise, or a message, to indicate that its done its thing?

“Beep” uses the selected system sound. Or you can have:
Message “Backup Copy Saved”

More options:

The nsnotify statement delivers a notification.

The speak statement speaks a word or phrase.

Thankyou both. Excuse my ignorance, but where do I put it in the above sequence?

PS: I’d already tried to put in a message, but it turned up as I opened the database, not as I used the hotkey!

The notice must be placed inside the hotkey code itself.

definehotkeys “database”,“control-B”,{makefolder dbfolder()+info(“databasename”)+" Backup"
    saveacopyas info(“databasename”)+" Backup/"+info(“databasename”)+"  "
    +superdatepattern(supernow(),"MM\DD\YY @ ",“hh;mm am/pm”)
nsnotify "Backup complete!"}

The nsnotify statement will give a notice in the corner of your screen and sound an alert.

Hello Jim,

We are perfectly aware that there is no such thing as software without problems (and we agree that Apple’s software is a constant reminder of this). I came here not to complain or criticize but to see if others had had a similar experience and maybe learn something. I always think I may be doing something wrong, or there is something specific with my setup causing the problem. If I’m not alone, I feel better and can often get good suggestions from other users as has been the case here.

We’ve been using Panorama for decades, since the OverVUE days. We hope to keep using it for decades to come :slight_smile:

Thanks for all the hard work.

Just this morning I came across some 400K floppy disks I’ve saved: Macintosh System Disk, MacWrite, MacPaint, Red Ryder and OverVUE. I had no idea that OverVUE (now Panorama) was going to be with me for so long, in so many ways and be as significant as it has been in my life. And happily, the learning curve continues because the product continues to move ahead.

Perfect. Love it. Thanks very much.

So - Jim I wrote you about this several months ago. Your response was that all databases crash. Obviously there is a problem here which I and others would like your attention for a solution. These crashes are all too frequent and result in rework to reinter lost data. Worse, the database may not restart. I as others have resorted to frequent saves so as to be able to recover. I submit this is outside the behavior of a well performing database.

“All databases crash” doesn’t sound like something I would say, so I went back and found the email you are referring to from last November, which I am reproducing here since what I stated was quite nuanced.

Ideally, Panorama should never crash. If there are identifiable circumstances under which Panorama X crashes, we fix that problem. So no, I have no advice on how to avoid crashes, if I did, I would change Panorama to fix it. Fortunately, very few people are reporting crashes with Panorama X these days. Each month, Panorama X cumulative usage is now well over 6,000 hours, so we are well past the beta test stage. The reported crash rate is very low. It would be great if it was zero, but that has never happened for any significant software project in the last 60 years of the computer industry. I’m sorry that you are an outlier in this. By the way, you mention that you never had a crash with Panorama 6, but I can assure you that Panorama 6 definitely would crash sometimes. We didn’t have the instrumentation on Panorama 6 to tell us the exact rate of crashes, so I can’t say if it is higher or lower than Panorama X, but customers definitely experienced crashes, just like any large software program.

It sounds like perhaps you have a database that has gotten corrupted. This is unusual but can happen, possibly due to a software bug, or an intermittent hardware issue, or even a cosmic ray. Seriously, cosmic rays can flip bits on a silicon chip, I wish modern computers included error correcting memory as a standard, unfortunately on the Mac line only the Mac Pro has ECC.

I’m not sure what the “reopen” button you are referring to is. It’s not part of Panorama – I think it is an Apple button that can appear depending on how you have set your system to respond to crashes.

That fact that you were able to recover from a cloud backup lends credence to the idea that the original database became corrupted from some intermittent cause. Hopefully you’ll have better luck going forward now that you’ve recovered from a backup. If you wanted to go even further, you could export all the data to a text file, then re-import it. That will “clean out” any bad bits in the database structure itself.

Any time there is a Panorama crash that is an issue we are concerned about. Unfortunately, crashes can never be reduced to zero, there are just too many complications, hardware problems, different operating systems with different drivers, etc. We keep track of all crashes to look for patterns to try and fix any problem that regularly causes crashes. Unfortunately, crash reports contain limited useful information, it’s rare that a bug can be fixed just from a crash report.

Note: In the three months since I sent this email, Panorama X usage is up about 15%, which to me is an indication that people are using it more and more. I wouldn’t expect that if it was crashing and losing data all the time. If that was the case I would expect the usage statistics to fall precipitously. I watch those usage numbers every day. And even though usage is up, crashes have fallen about 25% since Panorama X 10.1 was released last summer.

Panorama already has my daily attention. Though you can’t see progress on a daily basis, work is proceeding on a daily basis (usually weekends also). As I stated in my email, it would be awesome if crashes and bugs were zero on everyone’s computer, using every possible hardware and operating system combination. Zero is not possible, but I’ll work to get as close to that as can be, to maximize the benefit for the largest number of users.

I am currently doing intensive development of a large system. I haven’t kept a log but I estimate that I have averaged several crashes a week for several months. Some days, multiple crashes a day. I don’t report these but I believe that you get a report on them. When I get an automated offer to report a crash, does that report go to you or to Apple? My recollection is that it’s Apple.