However, when I open the database, only it is opening. I have tried opening it from favourites (as I usually do) or directly from the Finder. I have quit and restarted. Still nothing.
I have another set of files that have previously been set up as auxiliary databases, and they still open normally.
Can’t say whether this would have worked with the last build or not - its a while since I would have used this feature. It’s possible there’s some sort of activation step that I’m forgetting - but if not, it seems to be broken.
The screenshot shows that you have set five of these database to Open with no Windows. (You can check in the menu Panorama X > Memory Usage … if these databases are open.)
You can right-click on the green folder symbol and use the popup menu to uncheck this option.
Thanks Kurt, I meant to comment on that. I have tried with them visible or not visible. They are definitely not open. (I wasn’t aware of that way of checking however, so that is very helpful).
An update.
I was having trouble with programmes that have worked in the past, and couldn’t see what the problem was, so I went back to the last version of Panorama (3656) and retried everything. The auxiliary databases still didn’t work. However, this programme, that wasn’t working in the new version - sometimes added one record, sometimes added none, but never looped on to the other records - worked perfectly in the old version??!! (Sorry Jim)
I have not heard of any problems with the Auxiliary databases feature. I assume these databases open up ok if you open them manually?
If you want to compress the entire folder into a .zip file and send it to me, I will see if I can duplicate the problem on a computer here. If I can, then I should be able to figure out how to fix the problem.
That’s certainly possible if no records are selected by the select statement. In that case, Panorama will skip the rest of this procedure. You should use the info(“empty”) function to test for this, like this:
select sizeof(«RFID») > 0 and sizeof(«D») > 0
if info("empty")
message "no data!"
stop
endif
removeunselected
....
See the documentation on the select statement for more info about this.
Also, your loop can be done without the n variable, like this:
firstrecord
loop
post "updateadd", ...
downrecord
until info("stopped")
This won’t change the way it works, but is a bit simpler.
Also, I suspect you could replace this loop with a relational join, which would probably be about a thousand times faster.
Thanks Jim. Where would I find instructions on zipping the files?
Re the second issue I used exactly the same data set running it on the new version as the old - so data was definitely selected.
I would have loved to use the relational join, but ran into problems because I wanted the records added to have unique record ID’s, and I couldn’t get this feature to work with records added in this way (I did post about this question previously)…
The problem is that the Cattle-Database-Active-3 statement contains an .Initialize procedure that has a STOP statement. This completely stops Panorama in it’s tracks, so the rest of the database initialization process (including loading auxiliary databases) does not complete. If you remove the STOP statement (or change it to a RETURN statement) it will work fine.
I’m going to modify the STOP statement so that if it is used in the .Initialize procedure it will cause an error instead of stopping the procedure. Paradoxically, this will allow the rest of the initialization to work (because when an error occurs in the .Initialize code Panorama traps the error and displays a notification, but then continues with the rest of the process). But either way, you should remove the stop statement.
I also noticed that your Cattle Database 3 database has an .Initialize procedure that does a bunch of opensecret statements and then opens a form. I would suggest that you completely remove ALL of this code.
Thankyou. The .initialize procedures were being replaced by the auxiliary database - hence why I put the ‘stop’ in, to test before deleting. I had no idea that had an impact on the WHOLE process.
I didn’t realize it either – it had never occurred to me that someone might put a stop statement in an .Initialize procedure so it wasn’t set up to handle it.
For what it’s worth, I virtually never use the stop statement. I usually use the return statement instead. Then the code can be called as a subroutine if ever needed. If not in a subroutine, stop and return do the same thing.
FYI, I have made a change so that including a stop statement will no longer silently mess up the database initialization process, or other tasks that must not be interrupted in the middle (like server code, which must always return a reply, even if that reply is an error message). You’ll still want to remove your stop statement in these situations, but instead of breaking things completely Panorama will now display an error but then complete the task (in this case, loading auxiliary databases). If you’re interested in the details, the documentation for the stop statement has been updated:
Thanks Jim,
I’ve removed my stops, and made note to self not to do that in future anyway, but no doubt someone else will do the same thing in the future…
No doubt. Once the next version comes out, putting a stop statement in .Initialize won’t prevent auxiliary databases from loading. In fact, everything will work, but you’ll also see a notice that stop is not allowed in .Initialize.
