I had about 28 separate databases in Panorama 6 which I wanted to convert to Panorama X. The files were of various sizes, some had less than 50 records, others more than 2000. When I started the conversion process, Panorama X munched through the files at a brisk pace. Getting to about half the pack it started to slow down. Towards the end I had to watch the beach ball sometimes for over a minute. Did this exercise exhaust Panorama X? Is it collecting the files in memory, although I closed every file after conversion before opening the next one. Curious!
What does “munch through the files” mean? Was this some automatic process you set up?
Is it collecting the files in memory, although I closed every file after conversion before opening the next one.
No. When a file is closed, it is ejected from memory.
Did this exercise exhaust Panorama X?
It certainly sounds like it. But I am at a loss to understand why that is, at least with the limited information you’ve provided. There’s probably no one that opens and closes more databases than I do (though at 28 files you might be close), and I’ve never seen anything like this. I’ve been known to keep Panorama X open continuously for more than a week a times, it doesn’t seem to get slower, and it doesn’t seem to be leaking memory (I definitely keep an eye out for that).
If you quit and relaunch Panorama, does it resume the brisk pace? What if you quit and relaunch, then try opening one of the files you opened earlier (the Panorama 6 file, not the Panorama X one). Is it now fast?
You mention that some of your files had “more than 2000” records. That’s still tiny! In any case, the most complex part of converting a file from Panorama 6 to Panorama X is the forms. Do any of your databases have lots of complicated forms? However, even though ingesting forms is complicated, Panorama still normally does it very quickly.
Hi Jim, thanks for replying quickly. Here is some additional info, maybe that helps to discover the cause.
Whoops, the additional info is missing. Maybe you replied by email with an attachment? I don’t think attachments make it from the email to the forum.
What does “munch through the files” mean? Was this some automatic process you set up?<
Not at all. It was a conversion one after the other individually. Each converted file was closed before the next one was opened. Panorama 6 and Panorama X stayed on all the time.
If you quit and relaunch Panorama, does it resume the brisk pace? What if you quit and relaunch, then try opening one of the files you opened earlier (the Panorama 6 file, not the Panorama X one). Is it now fast?<
I did not quit Panorama X although, while the beach ball was rotating, this option was briefly offered (force quit unresponsive application, or something similar came up in a window). I discovered, however, that if I didn’t follow this suggestion, after an ever longer while Panorama X came back to life and completed the process. It only took an unusually long time.
You mention that some of your files had “more than 2000” records. That’s still tiny! In any case, the most complex part of converting a file from Panorama 6 to Panorama X is the forms. Do any of your databases have lots of complicated forms? However, even though ingesting forms is complicated, Panorama still normally does it very quickly.<
All the files had the same forms in Panorama 6 regardless of the amount of records. It was embellishments in the appearance of list view and single record view like coloured backgrounds, coloured text, buttons to invoke sorts, new records, pics, etc.
All forms were the same in all files, that’s why it surprised me that the conversion went fast in the beginning and then slowed down. After the conversion the list view form from Panorama 6 came also up in the converted file and I had to switch to data form to see the full new conversion in Panorama X. By the way, my Mini has 16 GB of RAM, just in case that matters here.
Thanks!
Guess I wasn’t clear. What I’m wondering is, if you go back now, start Panorama up again, and convert the 28th file again (but not the other 27), does it go fast or does it beachball right away?
I tried, as you suggested: no, this time conversion was of normal speed.
this time conversion was of normal speed
Ok, so Panorama X was getting tired!
If I understand you correctly, the time it took to open a Panorama 6 file was getting longer and longer. What about once the file was open? Did Panorama X run at normal speed then? In other words, was it just the conversion that got slower, or did everything get slower?
I shall try to describe more precisely, what happened.
In my understanding a conversion has 3 phases:
1.opening up a Panorama 6 file with the .pan attachment in Panorama X.
What this does is opening up also various views which were designed in Panorama 6 besides a new Data View in Panorama X
2.manipulation in Panorama X Data View (correction of soma data, adjusting column width, etc.)
Up to this point things happened at normal speed.
3. saving the converted file in Panorama X.
This is, where the beach ball started to rotate longer and longer. The various views are the same in all 28 files.
However, in my opinion the conversion is not complete until the file is saved.
To me, it seems, the slowing down has something to do with the forms. Converting other Panorama 6 files, which are simple Data Views without any designed forms, is fast (though I don’t have another 28 of this type).
Well that’s interesting.
in my opinion the conversion is not complete until the file is saved
No, the conversion happens immediately when the file is opened. When a .pan file is opened, it is immediately converted into Panorama X format. By the time the first window appears, the entire conversion process is complete. Panorama X doesn’t even keep the original .pan file in memory. There is no trace of it.
saving the converted file in Panorama X is where the beach ball started to rotate longer and longer
So that is really, really weird. There is very little processing happening when saving, and what processing is happening is the same as saving any Panorama X database – because at this point, that’s what you have, just another Panorama X database.
The format Panorama X uses for saving databases is actually a standard Apple format. So pretty much all of the heavy lifting is being done by Apple’s code. But the lifting isn’t very heavy, and I’ve never seen even a database with a lot of complex forms take long to save, certainly never seen a beachball. BTW, the time to save should be the same whether the database has a lot of windows or only one. All of the forms and procedures are saved every time, whether they are currently open or not.
So if you take these Panorama X files that you saved, re-open them, and save them, is there a delay in saving them again? Or did that only happen the first time? I must say, you have really stumped me on this one.
So if you take these Panorama X files that you saved, re-open them, and save them, is there a delay in saving them again? Or did that only happen the first time?<
As I have already tried your suggestion and opened the converted 27th file only again in Panorama X. There was a very short beach ball in opening 2 of the old views (forms) but more of it when saving. Not minutes, just a few seconds, until the old views (forms) closed. The Panorama X Data View table closed immediately.
Hi Jim,
meanwhile I was fooling around a bit more with my Panorama 6 & Panorama X files and conversions. It seems, that the forms created in Panorama 6 caused some problems in Panorama X. They were sort of converted but not fully, parts were missing. I could do some text corrections in these “converted” forms but when I tried to save then in Panorama X I got the message: Panorama can not save the file XXX because it doesn’t exist.
I got fed up getting nowhere with the old forms, so I deleted them all in Panorama 6 and then converted to Panorama X. Now everything works fine & fast.
I succeeded in making a new single record view in Panorama X which works. However, I don’t know, how to use this form with other 27 files, so that the form stays the same but the data of each file flows into it.
If possible, could you send me a file that demonstrates this problem? Ideally you would send me both the original Panorama 6 database and your final working Panorama X database, packed into a .zip file.
how to use this form with other 27 files
It’s easy to copy a form using the View Organizer wizard. And this is now documented in the 0.1.030 version I just released last night! Look for Copying Views between Databases under View Organizer.
To copy a form or procedure from one database to another, open a View Organizer for each database (using View>View Organizer). Then you can simply drag views across to copy them.
Thanks, exporting a form works beautifully now.
I’ll send you by separate email the smallest file in Pano 6 (with all the originally created forms) & Pano X with the newly created forms (Picture field is still empty because I could not yet delve into the manual to study this aspect). Converting the Pano 6 file with .pan will give you the problematic conversions of the Pano 6 forms to Pano X.
Thanks for helping to check!
Hi Jim,
since the latest version of Panorama X I am confronted with a new phenomenon.
Converted files from Panorama 6 which have various self-designed forms behave strangely after the conversion. As before, the forms are converted, not always completely (parts missing) but that is not the problem. They seem to screw up something in Panorama X’s behaviour.
It happened already on various occasions that I added new information to the converted Panorama X file in the Data View mode and opened also on of the converted forms from Panorama 6. After this I couldn’t save my work but got the message >The document"xxx (Panorama 6)" could not be saved. The file doesn’t exist< (although I was working on it).
There is no other way out of this but force quit. This means the newly added info is lost.
Obviously the trouble is caused by the converted forms from Panorama 6, because if I delete all forms and procedures in Panorama 6 and convert only the basic file, everything seems to work fine. Then, of course, all the needed forms have to be designed anew in Panorama X.
I did a search of my email and I cannot find that you have ever sent any files to me.
Another person on this forum (I think Michael Kellock) got the message
The document"xxx (Panorama 6)" could not be saved. The file doesn't exist
I think it turned out to be a permission problem?
I just did a google search for could not be saved. The file doesn't exist
and it turned up a bunch of results, this can apparently happen with just about any Cocoa application, including TextEdit, Xcode, Pages, etc. Here is my google search if you want to try it.
https://www.google.com/#q=could+not+be+saved.+The+file+doesn't+exist
Hmm, this page seems to indicate that it could be a problem with the settings for where the temporary directory is.
There is a lot of discussion here. This is apparently an Apple bug. One person says he has a solution, and a couple other people say the solution worked for him. However, I don’t quite understand what his solution is:
https://discussions.apple.com/thread/6043029?tstart=0#all-replies
No - you suggested that that might be the cause but it wasn’t. I didn’t ever find out why I was getting that message. I do know what I did to cause it and, if it’s of any use, I can try to reconstruct the situation. Let me know.
I may be wrong but I don’t think that Andras and I are the only people to have experienced this behaviour.
Wasn’t a randomized location of temporary files a security feature of one of the latest OS X upgrades?
I would recommend a change in your workflow: As soon as you have opened your Pan 6 file, save it as a Pan X file (and remove the appended name supplement “(Panorama 6)”). Then you can adjust your forms and procedures in the new Pan X file, and you should not see that error again.
Hi, thanks for the suggestion. I’ve tried it - up to now with 1 file only - and it seems to work.
It works in the sense that I don’t get the error any more , saving is smooth.
The converted forms from Pano 6 are useless because incomplete. They have to be made again in Pano X. But at least they don’t cause a problem any more