>>SQL server or one of the other well known backends, all have datatype support for VFP and beyond (even there is support for the general field but I believe nobody use general in VFP). You are asking this specifically for SQL server. You should be aware of depending on driver and what you use (RV,SPT, CA) you might not get what you expect from the backend. There is no "empty" date\datetime and FWIW you must set your date\datetime to accept null.
>
>Does this mean that one has to change all the empty date fields to hold a null before uploading and then change all coding to check for ISNULL() instead?

That, or check for 1900-01-01 in the cursors and blank those values. That will change the update status on those records, but then there's a trick - you set the cursor to non-updatable, do a tableupdate(), change back to updatable. Easy to do if you're using a cursoradapter.

>>If I were you, I would choose postgreSQL as the backend. If you ask why, there are plenty of reasons that may be too much to discuss here, so maybe just to keep it short it is said to be "most advanced open source RDBMS" - a truly open source one, you are free to do anything with it commercial or not. (as per the datatypes it has much more types than MS SQL server and not only that, much more built-in functions for them).
>
>Interesting...I had thought of it as this client also uses a document management solution from another company and the document meta data is stored in a PostreSQL server. The IT guy at this company has said that I should just take it over and rewrite it because a) the developer maintaining it is hard to get in contact with at times and b) most of the documents going into the documents store are pushed in via the VFP app. The only thing we have run into is that VFP has the 16MB limit on strings so on large documents, the users still need to use the browser interface to this other app.

That's the limit on string value in a variable (perhaps not even there, but many string functions may chop it) but not on a memo field. You can still do strtofile() and filetostr() straight with a memo field. I saw it work for a few hundred megabytes.

>Can you elaborate about "structures need to change" - if the table design is correct (which it is), is it only some field types that need to change? I still was not sure what to do about memo fields in the current table as someone said they are replaced by varchar/binary but it seemed like the limit was 8000 chars (which I think some of them are). Does postgres have a field type that corresponds to memo?

In SQL 2016 the allegedly doomed types of text and image (which wear "to be deprecated" tag for a number of years now) are still there and working as advertised. I use them for memo and binary memo, and have experienced no problems. As for Postgress, see https://www.postgresql.org/docs/9.5/static/datatype.html