Navigating form view within tab

[Grod]

Hi,

I have a fairly simple database with 4 tables -

> Customers

> Contacts

> Sites

> Survey_Results

All of these are related by idCustomer. In order to keep things simple for users I'd like to keep all information on a single layout (Customers). This is simple for Contacts and Sites as I just created a tab control set with each of these two tables in portal form on their own tab.

I starts to get complicated (for me at least) for the Survey_Results table. This table contains too much information to show in a portal (short of buying the users a couple of extra monitors to span the information across) so I have used a combination of tab controls and arranging the fields in a sort of form view, e.g. Tab_A contains fields A1-A30, Tab_B contains B1-B25 etc.

It all *looks* great, but I've now realised that I can't (or rather don't know how to) navigate between the Survey_Results records for the current Customer record. It only seems possible to display the *first* Survey_Results record for each Customer. If I change it back to a standard portal layout then the various navigation techniques I have tried (selecting set survey dates, navigation buttons etc.) all work perfectly, but I'm back to an unreadable mass of information on the screen.

Does anyone have any suggestions as to -

a) how to navigate the records?

or

: how to present the information in a different way that can be both easily navigated AND viewed.

Any help is very much appreciated, thank you.

[Vaughan]

In order to keep things simple for users I'd like to keep all information on a single layout (Customers).

Cause.

It all *looks* great, but I've now realised that I can't (or rather don't know how to) navigate between the Survey_Results records for the current Customer record.

Effect.

Tab_A contains fields A1-A30, Tab_B contains B1-B25 etc.

Are these non-normalised fields as well?

All of these are related by idCustomer.

Can you post your file, I'm interested to see how the tables are joined together. I think that that might be part of the problem.

I'd guess that SurveyResults should be related to Sites by a SiteID. Sites possibly should be related to Customers by CustomerID, while Contacts related to Customers by CustomerID.

A single layout can probably serve for Customers with a portal to display related Contacts, related Sites and SurveyResults. There should be a separate layout for Sites and maybe another for SurveyResults.

As for navigation and design, the FM Starting Point solution from Richard Carlton Consulting is a good place to begin.

[Grod]

Hi Vaughan,

Here's a copy of the file. I'm open to any suggestions and I'm very thick skinned, so feel free heap scorn on my design The last time I dabbled in database design was around about the time that FoxPro was first released for Windows, so I'm not so much rusty as seized solid.

customer_infrastructure_v0.2_copy.zip

[Vaughan]

OK a quick look:

Everything is on the Customers TO.

I imagine that you're trying to track things at customer's sites. If so, there needs to be a Site layout, and the Questionaire records need to be related to the Site record. As it is now the Question records relate to the Customer, not to the site.

Regarding the Questionaire table, I'd split it up into many separate tables. Maybe one table for servers, another for software... it can be done with one table, but not the way you've done it. Far too many fields. Putting data into such a system is a snap but the poo hits the fan when the data needs to be used for reports and statistics: there is no way easy way to count the stuff.

[Vaughan]

Just had another look at the Servers tab, this won't work.

Best to have a Servers table.

Have fields for:

Type, with values for Email, Database, File, Print

Operating System

Form Factor

UPS

Physical or Virtual

Vendor

Quantity is not needed because each server should have its own record. Just count 'em.

Actually the issue of virtual servers is interesting. It means that really there should be a table for hardware which records the processor, host OS etc; and another table for Services which would record the Guest OS, Software running, IP number, etc. Every server will have one hardware record and one Services record. (Or putting it another way, every server machine is running a virtual server, except some are only running one VM.)

Thus one physical box can be linked to multiple virtual servers.