Setting up relational database

Typically, yes. But in some situations I’ve found it preferable to build one database that contains all the code to run one or more others that contain the data. FarCall becomes a vital part of that coding.

A database can also contain all, or some, of the forms used by others, which can be printed using PrintUsingForm

1 Like

For a few months I struggled to get an answer to your question about those three relationships. The answer I always got was PanoramaX handles those functions with look ups, which are functionally not the same. So the bottom line is PanoramaX is flat file database. If you want a true relational database you’ll need to use FileMaker or, as Jim indicated below, something based on SQL .

“Relational” databases handle what they call relations through lookups, as well. Really, it is just a matter of the point at which the underlying file structure is divided.

Beyond that, Panorama has arrays and dictionaries, which are really miniature databases which can exist within a larger database. Panorama X has the new text list objects, which can work like FileMaker’s portals, as I understand it, that offer access to arrays, whether they are saved within one file, or made on the fly from another file.

It just seems like there is a lot more flexibility within Panorama, but with that comes the responsibility to pick from more options the way you want it to work. The difficulty with any database product is telling it what you want it to do, and that comes after what is the primary difficulty of any data process, deciding what you want it to do.

I finally decided to stay with my current solution (Numbers). My application(s) are fairly short-lived databases which typically have a varied structure each time I set up them. I currently do this using a Numbers document and different sheets … and the VLOOKUP function.

I’ve been thinking of moving to a SQL solution (there are a few things that are a bit cumbersome to do using Numbers and much easier if I had a “real programming language” that I could use) for a few years but I wanted some kind of graphical interface. I’ve been thinking of writing an app for this but since the the structure is different each time it would have been too much work either making a new version of the app each time. My main reason for testing Panorama was to see if I could get the gui part + the programming part in one package.

After playing around with Panorama I decided that the benefits I would get from Panorama would be marginal + some potential complications. So I decided to stay with Numbers.