Hello to the forum, I do not really know here further. If I create a form with more than 160 text fields I get this error message:



Does anyone have an idea how I can solve this? The fields all have a size of 250 characters (text).
Using latest Version of 8.5
With kind regards
Markus

Hi Markus.

Just tested in latest version of 8.5 and there is no problem creating 255 fields with 250 characters in each.

Here we did it gradually by first creating 100, saved, then added 50 and saved, then add 10 and saved, then added 10 and saved and in the end we added 100 and got error message that said we had exceed max fields and was left with exactly 255 as you can see from the image above.

Can we be so fresh and ask... Why do you want 160 fields of 255 in one form?

Hello and thanks for the reply. As you described it, I did it. I can also create all fields but always at the moment when I want to save and run into the user view comes the described error. Gladly I explain why so many fields are needed. We decided to import another database to Dataease. The data comes from an old WORKS database. Unfortunately, in this database is a form with 170 !! Fields with some slightly larger text fields. I had to save the data from WORKS as a TXT file with TAB separation without field names. This data I would then read again in Dataease. At least this is the plan. Maybe you have a more elegant idea?
Many greetings Markus

Hi Markus

Do you have any derivations?  An error in a derivation may be prompting the error.

i had a 200 field form to import data from an old system - and it works ok.

regards

josef

Hi again Markus.

Really strange.

Now I managed to re-create it.

Have sent it over to the technicians, only slight problem that the solution won't be available until 8.6 as we have closed release on 8.5

Hi again Markus...

We had a joke yesterday about OCD and prevalence in Computer Programmers. Many would say that it is almost a prerequisite for keeping track of a big codebase ;-)

Anyhow the discussion "took off" and we started doing a lot of internal "test" like:

What is the most beautiful number of 10.00 and 10.01 etc.

Obviously we went into decimal not being beautiful or even natural. Only binary and hex is really that ;-)

You had us a little with this one.

160x250 is 40.000 which is "beautiful" and would be to much of a coincidence if it hadn't been a computer that had the problem where this number is simply 0x9C40 or 1001110001000000 and as you see this is "nothing" and should not upset any computer.

So today we tested a little further to find where the actual "break point" is.

And it is at 130.98 fields which is not a significant number for a human but in this context a very significant number for a computer...

The trick you played on us was that you used 250 fields rather than 255 fields 0xff or 111111111.
If you had used 255 fields the cut off would have been 127.x fields not 130.x

130.98 fields is basically 32768 or 0x8000 or 100000000000 but in reality it means 0x7FFF or 011111111111111

And suddenly it all makes sense to a programmer (Sorry for the long winded explanation)

It is a sign bit problem and possibly it can have been there for quite some time.

It has nothing to do with the number of fields but the size of the record.

a 16 bit number can be between 0 and 65535 or between -32768 and +32768 and the function you use decide which as it treats the last (first) bit as either a double or a signbit.

No wonder we love this job ;-)

If you find joy in this explanation you do not have OCD but you are definitely a Geek!

As the explanation doesn't help you per se it will help you with finding a workaround for now.

If the fields are actually 250 then you simply need to split it up into two tables and import half of the rows in one and the other half in the other. Include the key in both and then simply join them up again in a form as a MainForm/SubForm(with one row).

Problem fixed and included in 8.6

Thank you for finding it and pointing it out. This problem has been there since DFW 5.x and maybe before.

Obviously nobody ever tested 255 fields of 255 before.