I'm working on a medical research database and considering moving (and not before time!) from embedded to SQL. One reason is to obtain a maximum number of fields of 4096 rather than the 255 we currently have. Looking at posts here I have found a comment by Vincent:

PS: I personally think that in general a table with 255 or more columns is very, very rare and it lets me think the data is not proper normalized. This is not true in all cases of course and you might have very good reasons to have rows with so many columns.

The time and trouble we have had because of this limitation is substantial. In our particular case we have had, in one case, to have 5 files linked to obtain what's needed. I suspect this may be true of other applications where there is a need for a large number of small fields (many just single character, numeric or date fields) and in my view this has always been a DAC 'blindspot', in the same way that the original Apple Macs (yes, I go that far back) could never have hard drives because one person thought that 3.5" disks were all that was required.

It would suit me to upgrade this system using embedded, then convert to SQL. It's much easier to move fields around in embedded and avoid some of the complexities of SQL until it's tested and ready to go. And do I really wish to have SQL on my PC where I do development?

The embedded DF system has been used wordwide for many, many years - and with great success. It rarely falters and is a pleasure to work with. Why is it limited to 255 fields?

Sandy.