Sharing database changes behavior

Panorama X Beta 10.2
1

I have a database that works fine in single user mode but after I share it, it won’t work properly. Something as simple as a procedure that loads a bunch of variables from one database, then opens the database in question and loads the variables into fields doesn’t work. It works fine if the file is not shared but throws errors when it is shared. For instance:

In DB1:
Local LName, LAddress
Name=LName
Address=LAddress
OpenFile DB2
AddRecord
Name=LName
Address=LAddress

In a shared DB2 database, I get the error that “Field or variable Address does not exist”. Each time it stops at different fields and says they don’t exist. If I unshare the database, the procedure works fine.

Also, in shared mode popup choice fields won’t advance to the next field when tabbed. I haven’t experimented too far beyond this as something is obviously wrong.

Has anybody experienced this?

2

The code you have posted will not work full stop, whether the database is single user or shared. It’s going to stop on the second line with an error that “Field or variable LName does not exist”, because it doesn’t.

Another problem is that you didn’t quote the filename in the OpenFile statement.

I suspect what you really mean is:

let LName = Name
let LAddress = Address
opendatabase "DB2"
addrecord
Name = LName
Address = LAddress

Since we really don’t know what your code actually is, it’s not really possible to help further at this time. But this sort of thing should work fine.

3

Ah, scrolling down spared you a second dose of what Jim said. You define LName and LAddress as locals. At that point they are empty - undefined. The you assign that “empty” content to Name and Address. Where did Name and Address come from, Are they datasheet cells, etc.?

5

You’re right. In my haste, I wrote it wrong. It should have been:

Local LName, LAddress
LName=Name
LAddress=Address
OpenFile “DB2”
AddRecord
Name=LName
Address=LAddress

Admittedly, this is how it was done in Panorama 6, but I’m converting databases I didn’t write. There are procedures in 4 other databases in the group that have similar coding that work fine when shared. Also, choice fields are not working properly in this database. I can’t tab out when the database is shared. They work fine in the other shared files.

6

One thing I forgot to mention, probably a big thing, these were shared Pan 6 databases. When I open this particular database named “Jobs”, it says it was corrupted. The users say they never get this error, but when I download it from the server I get the message that it is corrupted. In the past, I have always exported the data, found the corrupted records, deleted them, then imported the records. When I do that with this database, I get inconsistent data with some records that have information in the wrong fields. I can’t convert it to a Pan X database because it is shared and I can’t force it to single user because it is corrupted. I can convert it by adding .pandb to the name, but Pan X won’t open it.

Sooo, I asked my client to send me her copy. I was able to export the data and import it as expected. However, as I said, it works fine in single user mode, but it is funky when shared.

7

That definitely won’t work! If it’s a Panorama 6 file, you want to add .pan. All that does is let Panorama X recognize that it is a Panorama 6 file, because Panorama X doesn’t know anything about the old type/creator file codes that were used on the early MacOS systems. So Panorama X does not know what kind of file it is unless it has an extension.

If you set the extension to .pandb, Panorama X will think it is a Panorama X file. However, the internal structure of the file will be all wrong, so it won’t work, as you discovered.

I can’t force it to single user because it is corrupted.

Actually, you can. I think what you need to do is hold down the option key when you force to single user, but it’s been a LONG time so my memory is a bit hazy. But I know it can be done by holding down a modifier key.

these were shared Pan 6 databases

This really makes no difference.

There were some minor changes to the file format from Panorama 1 to Panorama 6, but emphasis on minor. For example, minor changes from 2 to 3, 3 to 4, and 4 to 5. When you opened an older database in a newer version, it would load the database into memory and then make the adjustments needed.

Converting from Panorama 6 to X doesn’t work that way. The Panorama X format is completely different. So instead of making adjustments, Panorama X creates a brand new database. It then picks out the various items of information in the Panorama 6 database and puts them into the new database. But no structure is kept. So if there was some problem with the Panorama 6 database structure, there is no way that those problems could be transferred over to the new database. They could cause the entire process to fail, but there is no way any structure problems in the old database can persist into the new database. It really is exactly the same as if you manually created a new database and then typed in all of the information from the old database. But the typing is automated.

Of course your new database does keep all of the coding in the old database. For example, if DB2 has a .Initialize procedure, that is going to run when you use openfile. Maybe there is something in the .Initialize procedure that is causing a problem.

One thing you could try would be to open DB2 ahead of time, and then use

topdatawindow "DB2"

instead of openfile. By doing that you eliminate all of the extra stuff going on at this point, synchronization, .Initialize, etc. If that works, then we know exactly where the problem is occurring, and can debug further from there.

8

Yes, once again interruptions and fatigue got the best of me.It should have been .pan.

Since the database worked with no records, I figured that even though I found the obvious corrupted Pan 6 records, there had to be more that I couldn’t pinpoint. So I imported the records one year at a time until it broke the shared file. Broke meaning the choice fields didn’t work and it kept telling me fields didn’t exist. So it seems to be working now with a set of records that my clients can accept.

9

It sounds like one of the choice data cells was corrupted. I’ve never run into that but if this came up in the future I think I would try changing the choice field to text in Panorama 6, then bring it over to Panorama X, then convert back to choice. But I probably wouldn’t have thought of that right away.