This is the first time I have a table with so many fields, this is why I have hit this problem now.
The table is well normalized (I even normalize physical addresses to a "addresses" table): it is the table that holds wages details for each month. You can biuld a table with a wage item on each row (idEmployee, idPeriod, idWageItem, value), or a table with one row per employee per month (idEmployee, idPeriod, all items).

I have been two months trying to make up my mind between one of the two approaches. I have even developed both of them in code (I mean full working code) to decide between one or the other. After many, many hours thinking about it I have gone with the one-record-per-employee-per-month approach. Tha means that the table grows in columns as the number of items grow. The limit of 254 fields is far from being a limit, even after legislation changes in 10 years.

As for the problem that arises from tables with many fields, I'm going to jump to the other thread, as I have never read about this, and I think is an interesting topic (I wonder why I have never read about this limitation).

Off the topic: the architecture of the temple looks impressive. As long as they will finish it, I'm going to visit it. If you ever plan to come, let me know.

Javier.


>I am afraid you are right. I reviewed the relevant help topics, and they are, indeed, quite clear, but I had previously overlooked them. I will have to change the options in my system (back to "key and modified fields"), and see if it works.
>
>With so many fields, the question arises if your tables are normalized. But even with normalized tables, you sometimes need many fields.
>
>I don't know how to solve this situation; I will continue investigating.
>
>For now, I tried to make the dilemma clear, in Thread #960857.
>
>Off-topic: You might be interested in this temple, which is being built near your city:
>
>http://news.bahai.org/story.cfm?storyid=223
>
>or
>
>http://temple.cl.bahai.org
>
>Saludos,
>
>Hilmar.
>
>>I used optimistic table buffering (5), and what I did was to compile the application into an EXE, and open two instances of the EXE with the same form.
>>
>>I put EXE1 into edit mode, go to EXE2 and put it in edit mode, make changes in several records (of the child table in a one to many form), go to EXE1 and make changes in the same records, go to EXE2 save changes, go to EXE1 and save changes (which overwrited changes in EXE2 without complaining).