>Hope you don't mind a few questions back at a time (running out of time today):
>
>>VFP developers are accustomed to drag & drop controls on to the form surface and work from there on, rather than doing things in code. Likewise, .Net have the same support in an extended way. It also have similar drag & drop support for your data backends (you need to see that in action to better understand). This is kind of a tooling, that writes code for you. If you are using MS SQL Server, then adding data objects (say an Entity Framework connection and building EF objects) is easier. With postgreSQL you may get frustrated not finding the same support and instead you need to write code yourself or do more google searches to understand why something doesn't have a visual builder, or how to enable a visual builder for that, things like that. But if you bear with that, postgreSQL might be the best choice made.
>
>- are you saying that with SQL Server that it has (or these Entity Frameworks have) a "visual" way to define the tables in the database whereas in PostgreSQL it is not visual? How are tables/relationships defined in Postgres? Or just that there are more visual "builders" overall for MS SQL (built into visual studio)?

In .Net there are some data access technologies that unifies the way how you access different datasources. Just imagine if it were another kind of an ODBC driver. Instead of directly coding against the backend, you talk to backend via some objects and you don't care if the backend was MS SQL, postgreSQL, VFP (yes VFP too), Oracle ... That layer's creation and usage as a source in forms is visual (say similar to modify Database tool in VFP). You create that using some visual tools and as you select your "provider" -the db driver- you see your tables, views ... to choose from and then you manage them visually.

When you want to do this, MS SQL have the best support in MS Visual Studio (same prefixes:). It takes some effort to find the correct files for say postgreSQL (but in time things might be better). And say, postgreSQL have a future called listen/notify, where using that feature with the older drivers are easy while with the newer drivers you need to be aware of removed connection properties and handle it differently. Things like that.


>
>(re datatypes)
>
>>Aha, I just suggested that superficially above. It is hard to show its strengths on a windows only world. It has better data types and yes that is one of the most important reasons. Those data types are ones that a VFP developer could only dream of. For example in postgreSQL you can have integers and strings as a datatypes, also array of integers or array of strings as a datatype (indexable, searchable arrays with plenty of useful functions). You can check its datatypes on postgreSQL.org site (https://www.postgresql.org/docs/11/datatype.html)
>
>I have seen that list before. In this app, the only data types we have *really* needed are: text (fixed length), text (variable length), numeric (up to 11,2 length), date, datetime, logical (occasionally could have used storing an array but not critical). Have not looked for the MS SQL chart of acceptable data types - do they have all the ones I use?
>
>Gotta go...supper's on the way!
>
>Albert

MS SQL have all the datatypes that you have in VFP and more. It just isn't as rich and flexible as of postgreSQL's. date, datetime reminds range and interval which postgreSQL have.