tantramar, one question to ask yourself is how the database is going to “grow”. It should grow in the number of records, not the number of fields.
For example (old man sitting on a porch chair whittling on a stick) … Long, long ago, Panorama had a marketing catch line, “The database that thinks it’s a spreadsheet.” This captured the attention of people who used Excel and often created reports with a time unit as a column heading and rows fixed into categories of various income and expense items.
The problem was that when they moved their data to Panorama, they copied the visual aspect of their data by using those time units, like weeks/months/years, as column headings, with the first column in the database describing the categories.
So, as time went on and new data arrived, they had to add more and more columns to the design. This caused all kinds of extra work and complications for them. It took a re-education effort to explain the benefit of making those “fixed” income/expense categories the fields (including a Date field) and adding the weekly/monthly/yearly data elements as records.
That way, they could add years and years of data and easily select any time period they wanted for their reports. They could structure a form, or even a Cross-Tab table, to display the result in a visually familiar fashion.
So, as you add new data to the database, it’s best to do it by adding records, not adding fields.
The “join” feature of PanX is so powerful. Once, I had to merge data from two databases holding tens of thousands of records. At the time, the only technique I knew was to pull data from one database into another using the LookUp statement. The process took hours and hours and hours to run. Then Jim suggested the Join feature. I tried it, and it only took seconds to accomplish the same result.
You have a great idea, using data and structure you know well to acquaint yourself with PanX. Go small. Go simple. Learn the mechanics. See how a join couples the data from two databases with simple examples that you understand.
One last example … (stick is almost whittled down), once I was helping with a database that had students and courses. The goal was to be able to have reports showing all the courses a student was taking(with their test scores), and reports of all the students signed up for specific courses. In the olden days (Pan6 and earlier), this required three databases. One was a list of students (with their demographic information), the second was a list of classes, or rather a class-teacher record. The third, the one that grew in records, was a “transaction” database that held records with student number, class number, some date data, maybe some test data (it was decades ago). That way, for each student, using the third database, you could select/display all the classes they took for any time period. And for each class, again using the third database, you could select any class and see which students had taken it.
With PanX, you can do away with the third, intermediate, database by using the relational features.
It’s so cool.
Pre-ProVUE, I used to write how-to articles for the “FileMaker Report”. When Panorama was introduced into the world, it solved/overcame almost all the limitations FileMaker had at the time.
You may have to do things differently in PanX, but you’ll be amazed by the speed and programming (Procedure) control. Like the boa constrictor eating the elephant (PanX is a BIG elephant), take it little swallows at a time.
Thanks!