Is the PanX trial version a fully functional, full feature version of Panorama?
Just want to make sure I am not spending tons of time trying to accomplish relatively simple db tasks that are not supported in the free trial version.
For example:
Want to create a simple text box that I can date and log details of a particular job. Tried text editor in a form and the text disappeared after I clicked on another cell.
Yes, the trial is full featured. The comment ‘after I clicked on another cell’ makes me think perhaps you clicked on another record which would make this happen.
I can duplicate that behavior if I don’t complete the setup of the text editor. If I just create the box, but don’t designate the field or variable it’s supposed to be editing, I can still type into the box, but there is no place for the text to be saved.
Thank you. So simple and often time consuming to find the answers in the manuals.
Now for the difficult part, a bit of history, and I do not expect a solution.
Have been running a construction company since 1982. Purchased first copy of Panorama2 on Oct.1991 and continuously updated through Pan6 and now trial version PanX. I have an entire list of serial numbers for updates, dictionary and zip code purchases etc. I am no programmer but I got this db to work decades ago and have been using it for 30 yrs.
Panorama has been monumentally important to my business. 5 thousand + records linked to 8000+ job photos, each record containing:
-
customer contact info
-
forms for line item estimating cost calculations and totals and % analysis
-
data linked to estimating forms, Contract form, job analysis form, marketing form. etc.
-
job scope search words
-
Daily Log text box of all customer conversations and running job data.
-
Photo image cells. included job concept sketchs plus job site photos
-
static standard text and company logo on the forms
-
search action procedures for finding all data we use daily.
One record on 8.5x14” legal sheets provides a through snapshot of the job that can be arrowed forward and back and searched all kinds of useful ways.
Back when I created this db I am sure my formulas we not as efficient as they should have been however the db up to Pan6 has worked flawlessly.
Now for PanX. Entered the .pan to the end file names and databases opened in PanX. Amazed the link between the photos and records worked. NONE OF THE CALCULATIONS WORK. 100 plus fields and many of them are formula calculations.
When PanX first came out Jim mentioned I may have difficulties having created db forms with the original early Pan versions.
In construction it is often easier to start from scratch than to rebuild existing. I may be into the old versions so deep that I may have to start new.
I am ready to retire and I want to hand this great database on to the new owner.
Panorama (and my great employees) have been the best part of the business.
Robert NY
It seems very unlikely to me that none of the calculations would work. Almost all Panorama 6 formulas will work just fine, only and handful of really super special functions would not work, mostly they would be related to operating system parameters, things like that.
If you could provide some concrete examples of calculations that you think are not working, including what you expected the calculation to do, I’ll bet that this can be cleared up quickly.
Another technique is to make a simple/sample database that only has the elements necessary to test the formula. Try it in that environment so you know it’s the formula that’s misbehaving (if it is), and not something else.
Thank you. Tried your suggestion and created from PanX templates a simple line item form to examine. This is how my old Pan db created 20+ yrs ago worked with no problems.
-
I tried to adjust my recently imported Pan6 to PanX db similar to the simple line item template.
-
I matched / designated, the form cell names to the field names in my imported PanX db.
-
I think a problem is the way my old field names are written.
For example quantity in line one my db is named: (Size/ Sq Ft 1), price field is named (Est$/SF 1)
-
when I try to multiply these field names I use the formula Size/ Sq Ft 1*Est$/SF 1
-
the way this formula is written does not multiply in Pan X
-
I therefor changed simplified the first 6 field names from Size/ Sq Ft 1 to quanity1, quanity2 etc. same with price and line fields. (like on the template).
-
Great, this multiplied the two fields in the record, as it should.
-
next problem was Tab. I get a message, Field or Variable [the field I simplified] dies no exist. I could not tab to the next cell
-
to advance I have to mouse to the next cell in the form.
-
Obviously want to quickly enter and tab through form cells to the totals.
Appreciate any help.
Spending hours and trying to get simple calculations to work.
Wondering if there Panorama consultants I can hire to get my old imported db working?
I have time now as winter is slow but when the construction season starts here in NY there is no way I can spend hours and days trying to get my db to work with PanX.
Robert
This formula would not have ever worked in ANY version of Panorama.
If a field name has unusual characters in it, it can be used in a formula, but only if you surround the name with « and » characters. So the formula should be:
«Size/ Sq Ft 1»*«Est$/SF 1»
I think this goes all the way back to Panorama 1 in 1988, and has always been documented.
Aha! There is a problem in the documentation. The key sequence for the chevrons does not print here nor in the documentation. The backslash character does not show up. You need to use it twice. Option-\ = « and Shift-Option-\ = ».
Robert1, I had a whole diatribe going about field names that was just “itch’n for a fight” as everyone has their own experience and preference. You just know that somewhere along the line Size/ Sq Ft 1 will result in PanX thinking you want to divide Size by Sq. That’s why you ALWAYS need to remember put the chevrons around those types of names.
But what if it were named SizePerSqFt1; (";" is not part of the name) It still tells you what it is. It doesn’t need Chevrons, and It won’t be misinterpreted as an arithmetic operation. If the line number scheme from Pan6 (and earlier) is the same in PanX, you still have the required numeric ending.
It’s a small point - and surely others will have a different opinion. From my perspective, there are ways of doing things that encourage problems, and ways to minimize problems. Naming variables is one of those areas.
Because of PanX’s new - compared to Pan6 and earlier - way of relating things, like item and price, It might be better to take what you like best in your earlier model and start with a fresh build in PanX.
It’s sort of like you can remodel a house just so much, but there comes a time when it’s better to just level it and start over - keeping what you’ve learned you like and what you’d want different in mind.
Ouch. This problem actually appears on ten different pages in the documentation. I have just fixed all of them.
However, that doesn’t affect Robert’s problem. He says that his formula worked in Panorama 6, but that is just not possible. I just now double checked to make sure the if the formula contains chevrons in Panorama 6 that those chevrons are accurately transferred to Panorama X, and they are.
Robert’s assertion is that formulas that worked in Panorama 6 no longer work in Panorama X, but these formulas can’t possibly have worked in Panorama 6. Formulas that don’t work in Panorama 6 will continue to not work in Panorama X. Hopefully Robert will chime in with an explanation of why he thought these formulas worked before.
Paul, I don’t disagree with you as far as philosophy of naming fields goes, but Robert just wants his existing database to continue to work the same as it did before – perfectly reasonable. We do now have a bit of a mystery as to how this database ever worked.
I emailed him and offered to look at it. I haven’t heard back - I replied to the copy of his “Thank you” post here that came to my email. I figured it would be rerouted to him.
I still have a HighSierra/Pan6 environment on a 12 yr old MacMini. If I get a copy of the file/s and solve the mystery of the field names without chevrons, I’ll post it here.
Had that email actually gone through, it would have appeared here on the forum, and depending on his preference settings, it would also have been sent to his email. Since your reply didn’t appear here, I think we can safely assume the email didn’t go through. Email to or from this forum is not very reliable these days.
Hi designer,
Appreciate greatly all the time everybody has put into responding.
All who have used my Pan6 db have been hugely impressed with all the function at a glance. Everything worked instantly. Customer data entry effortless , job description fields linked to sku numbers, line item multiplications and totals, and photo images worked most impressively. We just dragged a uniquely named photo/image into the photos folder and pasted the same name into the linked cell and the photos appeared in all the connected forms.
Have not looked at the Pan6 design sheet for years, until now. There is so much info, formulas, procedures and setting in those 125+ fields that am completely overwhelmed that could duplicate this or adjust it to work in PanX. PanX has no design sheet see all the fields at once to access. I spend so much time in PanX data sheet just navigating to the field I want to adjust. Then making the proper adjustments, unlikely will will work with my experience as a construction company owner with no programing training. Jim is correct when he said" it is a mystery how this database ever worked". It has worked phenomenally for decades.
So as you mentioned, start a new build in X as I have just begun 2023. I need to relearn lots. Got calculations line item to work. Having trouble linking sku numbers to description fields. Also having trouble sitting up images linked to each record.
Many of my simple Pan6 databased convert just fine to PanX. It is my largest estimating and analyzing db giving me so much trouble.
I am excited about PanX and I am willing to start fresh 2023. Want to sell the business to a long term employee and want to make the bookwork current and as effortless as possible.
That’s not what I meant. I’m referring to a very specific mystery. You claim that your formulas don’t have the field names surrounded by chevrons. But with your field names that have special characters in them, there is no way that formulas without chevrons would have worked in Panorama 6. That is the only mystery I am referring to.
That should work EXACTLY the same in Panorama X.
Maybe the path to the photos folder is different. That’s not really a Panorama 6 vs. Panorama X issue, but the path does have to be correct.
I’m guessing a large percentage of those are line item fields. You should look at this page.
A change with Panorama X is that line item fields 2, 3, 4, etc. will use the formulas and procedures for line item 1… but only if they don’t have a formula and/or procedure. So my recommendation would be to remove any formulas and procedures on all line item fields except for the first. So then you probably will only have a couple of dozen fields that actually have formulas or procedures associated with them.
For example, suppose you have a Total1 field with this formula:
QtyΩ*PriceΩ
This formula will also be used on Total2, Total3, Total4 etc., as long as you leave the formula option blank for those fields. Then if you ever need to change the formula, you only have to do it in one place. Even if you later add more line item fields, they will automatically work with the formulas and procedures set up for the first line item.
Robert1, one of the catch phrases for early Panorama was, “The database that thinks it’s a spreadsheet” - something like that. Problem was, people would “grow” their database as they might a spreadsheet rather than a database. I’d see many designs where fields would be added and added for dates and such when it would be more flexible/simpler if there was one date field and more records were added for additional dates. In general, where a spreadsheet might “spread” horizontally - quarterly time periods while the “rows” would be accounting categories - a database grows vertically and new dates become records and the fields across would be accounting categories.
When you mentioned 125 fields … that seemed like a lot. But maybe they are necessary.
It does take planning, and often revision along the way. For example, I might have a database where a field could have 6 choices. Do I want to make it a “choice” field - limited to the six - or do I want to bring the choices in from a different file? It’s a little more work with the additional file approach, but the benefit is, I can change those choices - add, delete, modify - without messing with the main database. Is it worth the time? Sometimes Yes, sometimes No.
I don’t know if it’s true in PanX but one thing that used to catch people up in Pan6 when using the Omega Line item feature is they would have other fields in their database (like Phone1, Phone2) that ended in numerics but had nothing to do with line items - and that would mess them up. So naming conventions are important.
Once you figure out the linking relational scheme - that in the past relied heavily on the LookUp function - it may shift your design to using more (linked) databases but simpler procedures.
Like eating a large piece of broccoli (leaving the elephant out because - vegetarian here), it’s small bites at a time.