Only 450 field display?

[GilloD]

Hey guys,

I'm pretty new at File Maker (I just started a new job and they just sort of handed me the manuals, heh) and I've got a question. I'm working on a rather large number of data entry fields (About 475 as of now), but it only shows about 450 of them on the table itself. Any after that show up as defined, but don't appear on the table for entry or modification. Any help would be well appreciated!

Thanks,

Scott

[-Queue-]

Have you tried putting the fields on the layout in Layout Mode?

[Ender]

You're trying to show 475 fields in a table layout? Not good. You should look at redesigning your solution to take advantage of FileMaker's relational abilities. Use portals to hold repetitions of the same type of data.

Your data entry and view layouts should be intuitive for your users. Something like a tabbed interface works well. You can have different groups of fields on different layouts. Check out the FileMaker example files to see basic examples of this.

[GilloD]

I've been considering that, I didn't quite realize the amount of data in front of me until I sat down to type it all out. The idea is that there is this master sheet (The 400+ field one) which other sheets refer to. It's a real estate thing, so there may be one sheet which talks about daytime traffic and rent, where another talks about rent (again) and gross taxes or something.

Anyway, I see your point and have another question- If I wanted to split this huge master sheet into 5 other sheets, is it possible to just drag my fields over or do I need to manually reenter field names/types? There's a heinous amount of repition (10 comments, all with 3 or 4 types of comments within. Ugh.) and I'd hate to get back into that, heh.

Thanks,

Scott

[Ender]

There's no built in way to duplicate tables or move field definitions from one table to another. You could print out the field list, jot down which fields will be used in which tables, then use that as a blueprint for entering the new field definitions.

I would highly recommend that you spend time figuring out your relational structure before going too much further. It will save you work later.

I haven't worked on a real estate solution before, but I can imagine that it seems right that the "master sheet" table would have a lot of fields. But if you think about building it with a normalized relational structure, you might see some redundancies. These redundancies can usually be eliminated with the effect of making the database easier to use.

As an example, properties are located in a state, city, neighborhood, with a specific address. If you had a table for Property, located at a specific address, in a specific neighborhood, the city, state, zip fields can all show up from related information based on neighborhood (you might need to enter city too if duplicate neighborhoods are possible.)