Hi,
My data is stored in an SQL database consisting of six tables. I have succeeded in importing one of these tables into a Panorama X database, but is at a loss as to how to import the remaining five tables. -Is this at all possible?
Strange
In Panorama you would have a separate file for each table. The data would be linked between the files using several unique Panorama statements and functions. You can read about the basics in the Help file:
and:
Note: Somewhere in the distant Panorama future I think it would be cool to have multiple named data sheets all within the same master file rather than having multiple linked files as used currently. All the field names on the various data sheets would have to be unique and each datasheet would be named and have its own block of data the same as if it was an external file. From the user’s standpoint it would simplify relationships and keep everything together in one single file including forms and procedures.
I would imagine Jim has most likely considered and discarded this scheme in the past due to some lethal ramifications only he would anticipate as the coder-in-charge. Just an idea that I thought might be feasible some day (in a galaxy far, far away…).
Gary,
Thank you for your detailed information, which has been a great help. - Unfortunately this information implies that Panorama X does not suit my purposes.
Thanks again,
Strange
The problem of exporting tables from your existing tables is a function of the software that you are using. If you can export the tables, Panorama most likely can import them. It will not be able to relate them in the way that they have been related without some work. But this is true of just about all database applications.
I’m a bit late to the party. I have a Filemaker database that has dozens of tables. If I try to organize a similar “database” in Panorama X, Would I put all tables of a “project” in one folder, and tables of another FM database in another folder, etc?
Sounds like a plan. Another possibility would be to name them with a common root name, but putting separate projects in separate folders sure sounds less confusing to me.
I tend to put related databases together in a folder. One thing to consider though, is whether you might ever want to open more than one set of related databases. Panorama can’t open two databases with the same name, even if they are in different folders. So if that’s a consideration, you might want to use a common root name for each set, even if they are in different folders, so that each database (aka table) has a unique name across your entire database universe.
Thanks for that tip.
As I explore PanX more, I’m keeping in mind my massive (for me at least) FileMaker “solution”. It has a menu system I designed which presents a unique form for each click of a menu item. So if I create a PanX “program” (I assume this means a top level form is first displayed) with similar menus, each click of a menu item displays a different form, replacing the previous one. (The menus I envision are a button bar at the top of the form, not menus that are embedded into the app menu). I would define all the databases (tables) used in the ”program” in one folder and each form would be stored within one of the databases. (I assume a form is not a separate file.)
Let me know if my approach described above would not be compatible thus requiring me to design a different one to be compatible with PanX. Thanks for your help.
Each Panorama database can contain one or more forms (a form is similar to what FileMaker calls a “layout”, and you are correct, forms are not separate files but part of the database they belong to). Within a window, you can flip to another form in the database using the goform statement.
However, it’s not currently possible to flip from a form in one database to a form in another database within the same window. You could kind of simulate that by closing the window and opening a new window in the same spot, but that would be a bit complicated to do. You would probably want to use the makesecret statement to close the current window, so that the database will stay open in memory even though it doesn’t have any windows.
There shouldn’t be any problem making a menu bar across the top of each form. It’s also pretty easy to embed menus into the app menu. In fact, for this application that might even be easier than using buttons in the form.