I hid extra fields, but still Panorama X does not insert fields where I want to add them. It adds fields at the end and the process for moving them where I want them does not work
You might have to show all fields for insert field to work, as it does work for me. I can also move the field left or right.
Attempting to Insert a Field with Hidden fields still has bugs. And with the new dimmed menu, the only option out is to Force Quit. No crashing. lol. Just Force Quit. Then later when I did show the hidden field, the newly inserted field got added far to the right of where it should have been added. And I could not drag it to where I wanted it to go. When I attempted to use the Rearrage Fields dialog, it showed the field already moved to the desired position but alas, it really did still appear back to the right of where I wanted it. A Quit and restart got things straightened out. I think I am going to go back to leaving all fields displaying.
I think that is a good idea. If you attempt to insert a field where there are fields that are hidden, it would be difficult for Panorama to know exactly where to put the field. No wonder it gets confused!
I can imagine a couple of ways this could be fixed. Probably the simplest would be for Panorama to check whether there are hidden fields and refuse to continue if there are. But that is for Jim to decide.
But it puts it where I want it, it just appears far to the right. Confusing I know. To expand on what I just said, if I attempt to use the Reorder Fields, it shows it in the right place in that dialog. If I quit and reopen, it appears in the right place. But immediately after creating it, it displays in the wrong place visually. You got to see it to understand I imagine.
If I had created a db with fields 1,2,4,5,6,7,8 and then later decided to add a 3 before the 4 field, I would click on 4, do an Insert Field ‘3’, and unfortunately it would then dispaly as 1,2,4,5,6,3,7,8. If I go to the Reorder dialog, that would show 1,2,3,4,5,6,7,8. If I Quit and reopen the db, it then displays as 1,2,3,4,5,6,7,8. It is just odd until you quit and reopen that db.
It is always good to speculate and give details when something comes up wrong. That makes it easier to track down and fix.
The file was a shared file but to add the field required a New Generation. After the Quit to get the field to show up in the right place, all records were locked. I had to reshare the file so as to be able to continue work.
Any change to field structure requires a New Generation. There’s no way sharing can work if different computers (including the server) have different field structure. The New Generation process ensures that there is never a moment when different computers are connected to the server but have a different field structure.
My point was that I did not need or want a new generation at that time. I merely wanted to keep working on it in unshared mode. I needed to do many things. One of which was to add a field. When it got added wonky, I could have kept working in non-shared mode doing other things that needed doing. But I had to Quit to get the fields to appear where they should be then and that returned the db in full lock mode. A bit confusing if I may as I couldn’t figure out what happened. It was working fine unlocked before the Quit. What happened? I did decide to try generating a new version and putting it back to shared to see if that would fix it and yes, it did. But then I immediately unshared it again as I had more non-shared work to do. I want to share it when I want to share it. Not when Pano X thinks I need to share it.
I’m just responding to the information you supplied, you said “The file was a shared file”.
What do you mean you “unshared it again”? Did you turn it into a single user database? In that case, there should be no way to even do a new generation on the database.
Panorama sharing is not intended to work that way. Once you’ve shared a file, the intention is that it would always be shared except when you are doing a new generation. Since doing a new generation prevents anyone else from using the shared database, you generally want to plan that for “off peak” hours when no one else is using the database.
If you make a database unshared (single user), do work on that single user database, then upload it again to the server, you will lose ALL work that any other user has done during that period. Panorama has no way to incorporate the changes that other users have made into your database that has been modified independently.
Please note that none of my comments on this thread have anything to do with the original question about Insert Field and moving fields. Your original assertion about hidden fields is certainly correct, there has never been a claim that this bug was resolved. I have added a note that apparently this bug also applies to insert field as well as to dragging fields.
I’m not wanting to beat this unecessarily but I’m not sure I’ve been clear.
Yes, the file is most often a shared file. The reality is that no one else has ever or will ever use it but I do put it into shared mode so to practice with the server and shared files. And in fact this situation that I am attempting to describe is a positive from that putting a file into shared more for practice.
The problem that I had was that after taking a shared file into an unshared state, which a developer does to make signficant changes, that file should be able to be used in a non shared mode through Quits, Restarts, and any other types of changes that occurs. It may be several days before the developer wants to turn it back into shared mode. What happened here, and was never an issue with Pano Server 6, was that after Quitting Pano X, the file went into a all cells locked mode. I had to reshare it to get it moving again. As I had not wanted to reshare it because I had more developer work to do, I then did a new generation to put it into unshared mode. It is fully understood that other users would be locked out during this time but sometimes that is just fine. The developer makes the rules as to when a product is ready to use. In my mind, Quitting Panorama should not force the end of a unshared session. The developer may want to continue working on the file in unshared mode through many Quits of Pano X. In this particular situation, I happened to Quit Pano X merely to see if the Field arrangement would rectifiy itself (which it did) and thus it was the ‘end of a a day’ with more developer work to be done and no need to end the session of being an un-shared file. Having a fully locked records situation was never a thing in Pano 6 and others will likely be stumped as well by this situation.
I’ve asked you if by “un-share” you mean unchecking the Share checkbox in the Database Options dialog, but you don’t answer this question.
Turning off this checkbox makes the database single user, full stop. Once this is done, it is no longer a shared file, Panorama has no record that this database has ever been associated with any server, it’s just like a brand new database that has never been shared. This is not a “mode” or a “session”, it simply is now a single user database, permanently. You should be able to Quit, restart, whatever, the file will remain permanently single user.
There is one case that you could run into the issue you are describing. If you save the database, then immediately open the Database Options dialog, unshare the database, press Ok, then immediately close the database without making ANY further changes to the database, Panorama won’t save the database and the copy on disk will remain shared. So when the database is re-opened, it would re-open as a shared database. This shouldn’t result in all cells being locked, unless when you unshared the database, you also deleted it from the server. If you did encounter this situation, the fix is easy – open the Database Options dialog, un-check the Shared option, press OK, then save the database. Voila, your database is now permanently switched back to single user.
I would like to eliminate this one edge case, but it’s not so simple so I haven’t figured out how to do it yet. For now, if you switch a database to single user (or in fact make any changes in the Database Options dialog), make sure that if you’re not making additional changes then you should immediately save the database after closing the dialog.
Ok. The world could die with semantics so let’s see if I can make this more clear.
Using the New Generation tab, I started? a new generation and changed it from a shared file to a file that was not able to be used by anyone else and was in my mind an unshared mode. (I do get that there is an Unshared db type that would be accomplished by the method you stated above.
While my shared file was in the middle of becoming a new generation, I then did one of the tasks that I needed which was to add a field and thus all of my previous words describing my trevails. If a developer chooses to Quit a session of Pano X with this db in the process of becoming a new generation, they then find the db in an all records locked situation when the reopen this file. They then have to complete the New Generation to get going again. If they were not yet altering Field types, names, positions etc, they will then have to start a new cycle of New Generation before doing anything else because it is all records locked.
BTW, when I just now attempted to examine the tabs, etc, to get my nomenclature correct, when I was on the New Generation tab, everything locked up with the dimmed menus. Waiting did allow the procedure to time out with the Close Dialog / Wizard dialog which then ended up with another all fields locked situation. When a developer has started a New Generation, they should be able to close or quit Pano without that action ending their development process and the forced end of the New Generation cycle.
This is faaaaaaaaaaar outside the intended mode of operation for a new generation. This feature is designed with the intention that you will plan the changes you want to make, start the new generation, make the changes as quickly as possible, and then upload the new generation. If this is a production database, everyone else is locked out until you upload the new generation.
Even though you are not using this as a production database at the moment, I would still advise that you use the new generation feature in this way. If you need to change the database structure (insert, delete or rename a field) then start the new generation, make the change, then end the new generation. All other types of changes (procedure code, forms, field options) don’t require a new generation that pauses sharing.
If you really do want to operate in single user mode for an extended period of time, I would recommend that you completely unshare the database, then share it again when you are ready. Since the database has no other users, this shouldn’t be a problem. The new generation system is really to make it simpler to distribute changes to other users on your network. Since there are no other users, you can skip it.
All that said, I do agree that the way it works now is not correct. The problem is that when opening a shared database it does not recognize that the database is paused in the middle of creating a new generation. I looked at the source code and this was actually done intentionally, as I considered that this was basically an error. I will revisit this, but this is a low priority item because this is definitely not the intended use case for this feature.