Portal Horizontal Size Limits

[Kball1]

I am new to FMP, but have done quite a bit of database design work in MS Access. In access I could create a "subform" (i.e. - portal) that had both vertical and horizontal scroll bars. I could even "freeze" columns so during horizontal scrolling I would be able to see the key field - for example a part number - and its corresponding "technical specifications". I have tried the same type of arrangement with a portal, but it appears as if it is severely limited in its ability to handle more columns of data then what fit in the portal. Am I missing something? Is their a different way to accomplish what I am trying to do?

[Genx]

Unfortunatley FM doesn't support horizontal scrolling in it's portals. In terms of what you're trying to do, IMHO ... It's bad interface design that causes you to have that requirment in the first place (not that in some cases a horizontal portal wouldn't be amazingly useful).

[Fenton]

I guess the "different way" would be only show some of the data in the portal, and add a button in the portal to Go To Related Record on the portal's relationship, specifying a list view (or table view) layout of the base table the portal is looking at. This can be done in a New Window, so that it can be closed after viewing. Or flip back and forth.

Go To Related Record will go to all the records in the portal, landing on the one you clicked on in the portal. Or a button above the portal, running the same script, will go the 1st of the relationship. The layout can be any layout of the portal's base table.

[LaRetta]

IMHO ... It's bad interface design that causes you to have that requirment in the first place

I disagree. Even Approach had cross-tabs (and horizontal portal ability) which come in VERY handy in database environments. In fact, if you review all forums, you will see thousands (upon thousands) of requests for horizontal portals (and cross-tabs) and you will find advanced techniques by top Developers attempting to replicate that functionality. It does not point to poor structure nor poor interface design.

[Genx]

Each to their own i suppose. As i say, it has it's share of uses... but portals are used for an overview of related data more often than providing all information in a related table. As I said, it's just my personal honest opinion so let's not start anything here .

[Kball1]

I am curious as to what would be the better design option? In my past Access development I have had the name of the product line and one to one information about that product line linked to a portal which contains all the specific part numbers for that line and the subsequent technical data that will not fit in a single portal.

Any suggestions?

[Kball1]

I am assuming by your comment that FMP will not do crosstabs?

I have used these quite successfully in past development work.

Thanks

[LaRetta]

Not natively. But there are ways; one of my favorites is by Mikhail Edoshin here .

[Fenton]

I don't see why you couldn't do pretty much the same thing in FileMaker. You can have side by side portals, where a choice in the 1st portal controls what shows in the 2nd, and the 2nd in the 3rd. The 3rd could be the details of just 1 record, in which case it doesn't really need to be a portal, just the related fields (a portal just being a device to show multiple related records).

You can set either a global field or a regular field in the current table to control the portals, when someone clicks on a row to make a choice. Using all global keys would make the choices persistent across parent records, when flipping through the records, which may or may not be desired. Using a regular field in the relationships ties the portals to the parent record.

The trick is what to do if someone goes "backwards," that is, makes a new choice on the 1st portal. With global keys you would need to clear the subsequent keys, if otherwise they'd leave illogical data in the rightmost portal.

If you need more space for the 3rd portal it can open in a new window, appropriated sized and located. But then you need to take care of closing it, or selecting it (if already open).