SQL Server and IDENTITY column

[Mark Phillips]

On Jan 16, 2019, at 2:49 PM, Bastiaan Olij <bastiaan.olij at instinctsystems.com.au> wrote:
> 
> My beef here is that I had to write this table class (there is a lot more in it then handling primary keys properly), open up Omnis Studio for the first time and you have to write all this boiler plate code to make it work. Mind you, I don't underestimate the challenge here because as much as SQL is a standard, that standard doesn't cover half the stuff involved here and the way SQL Server does auto numbering fields is completely different from PostgreSQL.

As another said, more than once, what I like about standards is that there are so many to choose from.

I use the Table class to do a lot of the same work Bas refers to. It works quite well. 

I have added a number of object classes that are subclasses for the DAMs. These allow us to tailor server specific behavior close to the DAM. Together these classes support a simple abstraction for defining and populating lists and rows at the application level as well as the CRUD operations. 

We don’t allow user interface elements, like an Ok messages, in the Table and Object classes that deal with the DBMS. That is to allow them to be used in a server situation. It requires the UX classes to interrogate the objects for state. A bit challenging at first, especially if your habit is to sprinkle modal dialogs through your code.

All in all it works pretty well. In practice, we work mostly on Postgresql so the hooks that support other DBMS are present but lack proper elaboration. So, for example, ODBC works ok, as does MySQL, but there isn’t much for the other DBMS such as Oracle.

 - Mark Phillips