Saving specific Portal records

[Ren Fox]

I have several Portals set up to record specific Product pieces of data. All the portals are unique to each record except the first one.

Portal 1. Product Name: Notes/Data sheets/Documents

Portal 2. Product Reference/Order Numbers/Prices

Portal 3. Product Images

Portal 4. Product Monthly Sales sheet

All four Portals will relate to one Product per record as if that were my Topic/subject. The first portal will not change from record to record unless a different product is entered. For instance if I name that Product : PTP1B, I want the 1st Portal to save and remember everything I have entered underneath it in the notes or documents sections so that if I ever create a new record with the same Product name (PTP1B) it will auto-populate the record for Portal #1. The other portals will change based on new numbers or data entered each month. I want the first portal to auto-populate based on the name entered, but all other Portals to require me to type the info in.

Since there are multiple fields as well as types of fields in Portal #1 I am having issues with the save and auto-populate feature. Each time I try to make it work I still have to start typing in each field before something pops up, but I want everything to enter automatically once I type in the Product name.

Any suggestions?

[Vaughan]

Why are you doing this? Why not just scroll through the products table?

[Ren Fox]

Because this is not actually for a Products database. I am just using it as the example because it is the easiest for people to understand. If I went and tried to describe it as a Cryopreservation of Genetically altered strains and genotypes database it would just confuse people. These are the requirements from my department for the database they want to create.

~Ren

[comment]

If I went and tried to describe it as a Cryopreservation of Genetically altered strains and genotypes database it would just confuse people.

It confuses me now. Portals show related records. This part makes no sense:

All four Portals will relate to one Product per record

I think you have a parent table of Products (as if) and 4 child tables? Now what do you mean by:

The first portal will not change from record to record unless a different product is entered.

Entered where? And what does "not change from record to record" mean? If you want that portal to show ALL records in the child table, use the x relational operator when defining the relationship.

I am afraid the rest is a complete mystery to me.

[Ren Fox]

So, the first portal will actually have a section in the header listed as Strain name a field to type in the strain you want to view, much like Product name. When a strain name is entered on Portal one (Parent Table) the other Portals (child tables) will automatically list that strain name on them and pull up records from our Cryopreservation database files (mostly Excel based). So, these tables will change based on what Strain is typed in and any changes made to the Excel spreadsheets. There will also be sections to fill in for dates, numbers, and any other notes made monthly to keep track of that strain's progress.

That first Portal though will have attached Protocol information and data about that genetically altered strain for the reference of the research community that will be working with that strain. This info will never change for each strain, but will change between different strain names. This is some of the most important data to the researchers, but I will use the database to report current data on the other Portals. So once typed in I do not need to continually type in the same info every time I make a new entry for that strain.

Here is the tricky part. Portal one will always be the same if typing in the same strain name. However each researcher will have a different set of cryopreservation records. I separate them based on ID names and serial numbers. For instance strain name APN can have six researchers = 6 records. That means all the other portals will change based on serial numbers typed in as well, but Portal one will never change. So, when I am working with different serial numbers in the other child tables I still want the parent table to stay the same without me always having to type in the data each time a new serial number is entered.

Does that make any more sense? The problem is, it does to me and to the people I work with here, and we know what we want to do. But, conveying that to other people is proving to be challenging without physically showing what our database currently looks like and how it functions. We started this years ago with FM6 and now we are recreating and improving it with FM11 based on feedback from our scientists on what they want.

Thank you for your help.

[comment]

It makes no sense to me, I'm afraid. I suggest you name your tables and explain the relationships between them, before getting into portals and other technical issues.

When a strain name is entered on Portal one (Parent Table) the other Portals (child tables)

This is where you lost me. A portal shows records from a child table. The portal is placed on a layout of a parent table.

[Vaughan]

Because this is not actually for a Products database. I am just using it as the example because it is the easiest for people to understand.

There have been numerous occasions when people from the list have invested their time and expertise to suggest solutions to the problems as posted, only to be later told "Thanks but that's not really the problem, it's actually something completely different..."

Hence the frequent requests to post real problems and not just simplified abstractions that the posters think other people will find easier to understand.

Anyway, I think you should work on getting the data structure correct THEN work on building an interface that people can use. Be open to new interface designs that the new data structure will make possible: build an "old" system and a "new" system and test which offers the most usability (test it on people not familiar with the old system as well).

I have done work for organisations where I have changed the interface significantly from what the previous developer had done, despite requests to leave it alone because that they like it just the way it is, and the users found it significantly easier to use and changed over happily (and quickly). The old system was designed the way it was because the data structure was completely wrong as a consequence of the original developer having no idea what they were doing.

There is a quote from Henry Ford that says if he'd listened to what his customers wanted he'd have made faster horses.