One Record with many fields Display

[Anuviel]

Hi., I have a settings layout where I have about 150 fields (300 total, 150 regular and 150 global where global = regular so that global fields problem when more then one user uses the db is avoided). The layout is restricted to one record only.

I made a self join via foreign key and what I would like to do is:

Display 150 fields in portal (or something similar) so that they will fit onto one screen and no scrolling of the layout is required.

Scrolling of the portal would be fine. I cannot figure it out as the portal scrolls only when it has more then one row and as I have only one record to display it would mean one row only.

Thank you.,

[Anuviel]

Forgot: would like to have the fields arranged in vertical order rather then in horizontal.

[LaRetta]

1) I have about 150 fields (300 total, 150 regular and 150 global where global = regular so that global fields problem when more then one user uses the db is avoided).

2) Display 150 fields in portal (or something similar) so that they will fit onto one screen and no scrolling of the layout is required.

3) Scrolling of the portal would be fine. I cannot figure it out as the portal scrolls only when it has more then one row and as I have only one record to display it would mean one row only.

4) Like to have the fields arranged in vertical order rather then in horizontal.

All points make me shudder. Where in heavens did you get the ideas to design this way? You have taken a simple program and made it way overly complicated. By using one global for every field, you will be forced to track user possession yourself and you will fail. Because of Item #1, Items 2-4 are nightmares: You now have twice the fields needed and it will continue to grow. You don't need 150 fields in a portal for goodness sakes - you need a standard form view which FileMaker provides natively. You don't need to control the scroll of a portal, you need a form view. You want the fields in vertical? Again, use a regular form!

Sure, you can script control setting a global to each next ID, but unless you are an advanced Developer, you shouldn't be touching these types of concepts. And regardless of your skill level, attempting to control user possession of records is just wrong.

I highly encourage you to re-think your design NOW before it drives you to insanity.

LaRetta

[Ender]

Listen to LaRetta! She knows about insanity. :

[Anuviel]

Thank you points well taken. Maybe I have not explained well enough or I have it wrong.

I have read in the white paper (forgot what white paper it was, here on the forums) that when sharing the db the global fields will revert to what was in them originally (entered by the host) once the other users close the file.

This is the part where I am most likely wrong: I use the regular field to store settings for my calculations. A global field then equals the regular field so that a value for the calculation is available in every table and so forth. Maybe I should just use the regular field in my calculation and loose the global fields?

Basically my company sells on eBay and I have made a simple inventory program that also calculates eBay selling fees. Due to the nature of the fees the calculations are bit complex (I would call them that) and the values for the calculations are stored in the settings file rather then in calculation so that when eBay changes their prices I can simply type the new value in the settings field instead of having to hard code the value into the calculation.

attempting to control user possession of records is just wrong.

I am not trying to control user possession of the record. If I am missing something here or not getting something please point it out so that I can learn.

150 total fields are used because I have 150 different price tiers plus all of the eBay options and I just use that to store the actual numbers that are used in the calculations.

I prefer those 150 fields in a form view however 150 fields is a lot and for me to organize / make nice layout - it make the form view rather long so that it needs to be scrolled to see all of the fields. That is why I thought a portal view or something in which I could put fields in to achieve my goal.

My skill level is low, started FM about the same time I joined forums. I really like it and do hope to get good in it so whatever advice you give or direction you point I will learn from it.

Thank you.,

[LaRetta]

Hi Anuviel,

I came on quite strong but I was greatly concerned about what I envisioned you were doing.

Alright, well, because you don't have tabs (vs 7) then you'll have to come up with something which breaks those 150 fields into a few logical chunks. These chunks can be placed on different layouts. You can use buttons which even look like tabs (placed at the top) to navigate, which defines each group name. Or you can just use arrows which go forward/back but which actually scroll through the layout.

I have the feeling you will do alright on this project - you are staying open-minded and non-defensive and, most importantly, you are plugged into FM Forums which is simply the best training tool in existence. I'm sorry I couldn't come up with something more clever - I'm wiped out tonight (but I'm unsure I could come up with any other approaches anyway). Maybe others can suggest clever alternatives.

In fact, hey Mike?! Mike Ender? You there? Help this insane woman out, will you? Me, I mean! Clever boy - I'll getcha back one of these days! ROFLMAO!!

LaRetta

UPDATE: Oh, in case someone wonders why I added that last sentence:

Listen to LaRetta! She knows about insanity.

Did you really think it would slip by me? :joust:

[comment]

150 total fields are used because I have 150 different price tiers

Price tiers seem to me to be in the category of data rather than settings. It's hard to understand why there would be a need to access them without a relationship. Without knowing more about it, I would say you should have 150 records in a table.

Especially since, as you say, the values are likely to change. Having a calculation depend on global fields is not that different from hard-coding the values: in both cases the result will change when a value is modified, and history records will become modified. You should lookup the current value/s into a new record upon creation.

ADDED:

Since you only want to lookup the relevant tier price, a relationship to find the correct price tier is essential - so there really is no reason to go with the globals.

Edited September 7, 2007 by Guest

[Anuviel]

Thank you. All info and input is appreciated greatly. I am keeping an open mind regarding my project and will take all the advice I can get.

You can use buttons which even look like tabs (placed at the top) to navigate

I cannot believe I missed that - more because I am employing that in my other layouts.

in both cases the result will change when a value is modified, and history records will become modified. You should lookup the current value/s into a new record upon creation.

Basically I use the calculations to give me the costs for selling on eBay. I am not interested in history and once a price changes if all of the records get updated - perfectly fine.

I have included 2 files here. The one called a-sysbackup has 1 test record in each table and there you can take a look at my eBay calculations and let me know how "badly" I am doing. The other file would be the real file as the first one is used by me for testing and initial creation which then gets updated and made into the other file. The second file has no records and many scripts do not work as it is in development.

Hope my calculations will make sense, if not let me know and I will try to explain better.

If after seeing the files, what is recommended here is the way to go I have no problem in updating my file to that structure.

Just think a look at the file is necessary before deciding.

Thank you so much.

A-SYS_CopyBackup.zip

[Anuviel]

Oh yeah, login name for the files is Anuviel and the password is 12345, almost forgot :

[comment]

I am not interested in history

Even so, price tiers should be records, not fields. In general, any time you find yourself creating fields with appended numbers, like Price1, Price2, Price3.... that's a sign of wrong structure.

[Søren Dyhr]

Perhaps a jullup of jam, would make you swollow the whole concept ...individual portalrows can be cut up, and scattered all over the layout.

Comment is right, you're stuck in the wrong metaphor! What you here have committed is a classic one.

--sd

[Anuviel]

Ok then, guess I will have to remake that into records.

Thanks.,