Convert data in an outline to Pan X

I used the late, great, lamented Circus Ponies Notebook for all kinds of notes and record-keeping. I have a data set I would like to port to Panorama X. Any suggestions on how?

The outline is set up with unique top-level alpha-numeric identifiers. Each top-level identifier (the Parent) has children: always an image, one or more aliases for the top-level identifier, and my text notes. There may be up to 20 of these child-items. Some child notes have child notes of their own.

The fields I’d like to end up with are at the very least:

  • Top-level identifier
  • Image
  • Alias1
  • Alias2
  • Alias3
  • Alias4
  • {Etc.}

In NoteBook, what I currently have was set up for ease of use:

  • Top-level identifier
    • Note
    • Image
      • Alias1
        • Note
        • Note
      • Alias2
        • Note
      • Alias3
        • Note
        • Note
      • Alias4
      • {Etc.}

I am consolidating collections of photographs. The images have information in their filenames, but the information is coded in different ways (more or less: Roger, Rog, RD, RDoe, etc.). One of the ways I want to use the PanX version of the dataset is to query it for the new unique ID and add this a prefix to the file names (“RD01”). At the most basic, I want to turn my outline into a look-up table.

My thought is to flatten the outline to a table and import that. The columns would be:

  • Unique alpha-numeric ID
  • Unique human-language ID
  • Alias/Collection1
  • Alias/Collection2
  • Alias/Collection3
  • {etc.}

Which brings up a difficult (for me) question:
Is there a better structure than simply having as many fields for Alias/Collection pairs as I need? Note that the Aliases are not unique and are, in effect, unlimited. The Collections are unique and are quite limited (twenty now, almost certainly won’t exceed 50). Each “Alias/Collection” pair is unique. Currently I have about 600 unique top-level identifiers, and 3,000 Alias/Collection pairs. This represents the bulk of the data I intend to use for this project.

Thanks for reading and considering.

As a start, make a file of the 600 top level identifiers with unique IDs. Make a second file of aliases and link each alias record to its top level Identifier using their unique ID. Each alias record will have it’s own unique id in the alias file. In the top level file, create a form for each TLI with text list or matrix that will display all the aliases associated with each top level identifier. Clicking on an alias could bring up a form with their information.

Thanks — that’s a ladder to a new level for me.

Three simple follow-up Q’s from a newbie:

  • By “file” you mean a PanX database?
  • Is it common practice to use multiple PanX databases this way?
  • The link is made using lookup( or one of the lookup( variations?

Assuming “Yes” and “Yes” makes things much clearer to me. Is it safe to regard each PanX database as a flat-file (used to be called), and that one joins as many of these as needed to make a relational database?

Thank you.

KirbyKrieger http://forum.provue.com/u/kirbykrieger
February 28
Thanks — that’s a ladder to a new level for me.

Three simple follow-up Q’s from a newbie:

By “file” you mean a PanX database?
Yes

Is it common practice to use multiple PanX databases this way?
Yes

The link is made using lookup( or one of the lookup( variations?
There are many ways to link databases; lookup( is one.

Assuming “Yes” and “Yes” makes things much clearer to me. Is it safe to regard each PanX database as a flat-file (used to be called), and that one joins as many of these as needed to make a relational database?

Don’t know that I’d call each database a flat file as each database can have its own relations but, yes that’s pretty much the way it works. I’d probably call it relational system or relational solution or relational set or ….

1 Like

Works for me :blush: . Thanks for the following up.

The terminology is a bit different than systems like SQL. Panorama goes back to before SQL was in wide use.

A Panorama database is pretty much like a table in SQL. In SQL, a “database” can contain multiple tables, but in Panorama, each database contains only one table. If you need multiple tables, you create multiple databases, each with one table.

Aha … thanks. “Table” clarifies things a bit (for me).

Is there a tool in PanX that let’s one examine and/or create/edit relationships between databases? Is there a suggested method of grouping databases that exchange data?

Do any of the sample “databases” use more than one PanX database file?

The samples, the Help, and the tutorials are exemplary. Worth a year’s subscription, as far as I’m concerned. Thank you! I wish that all software were as well documented and presented.

There is no tool to create relationships between tables in Panorama. The relationships are created within each table (file) in Panorama using functions such as LookUp().

There is no limitation on placement or grouping of files within the directory structure of the computer. While it will be a default that a related table will be in the same folder, a related table can be placed elsewhere while you reference the location in your LookUp() functions and the like.

1 Like

Thanks.

Is the recommended practice to group each set of related PanX databases, along with all supporting files (for me, images) in a like-named folder/directory? I’d like to keep things simple-to-undertstand from the get-go, which for me entails making obvious that the databases are related (by, for example, putting them and no other not-related-to-them database files in the folder).

The placement of files is 100% up to you. Do what makes sense to you.

Yes, putting all of the tables (files) in the same directory will make your job a bit easier in that you will be able to allow your functions to use the default expectation that the associated files are in the same directory.

Personally, I would have all of my images in an images directory within the folder that contains your tables (Panorama files). But then too, it is a matter of the potential number of images. If you are speaking of just 3 or 4 company image files, then yes, you might put then together in the tables directory. But if they are images of the products that are records in a Product table, you would be better served by having an images directory.

1 Like

Thank you! It was a lot of work, nice to hear that it is appreciated.

That’s something that is under consideration for the future, but at this time, you essentially specify relationships “on-the-fly” by using various functions in formulas.

Of course the formula may be in procedure code which makes it more or less permanent, but Panorama doesn’t explicitly keep track of the relationships specified in the code. That is what we are considering for a future version.

In memory, there are no distinctions between databases in different folders. So from a Panorama operation point of view, it doesn’t matter what folder a database is in. (A side effect of this is that you cannot open two databases with the same name, even if they are in different folders.) But yes, usually you’ll want to keep related databases together in the same folder just for your convenience.

1 Like

How is this link made? I feel like I’m missing an obvious tool or concept. I don’t see how Lookup( would work since I am only trying to link each record in database2 with a record in database1. I could manually enter the unique-in-database1 value, but I’d like to select it from the values in database1 (and, more advanced, add a record to database1 when the currently entered value in database2 does not exist in database1).

@admin seems to indicate (and now, while I waited for the forum bot to let me post this reply, helpfully repeated in this thread) that links like this are done as needed. Using the tutorial Checkbook example — how would one set up a database of Categories, and how would that be linked to the Checkbook database?

This is moving off topic. Should I start a new Topic on “linking” databases?