Here is a video to illustrate the article: Generating meaningful test data using Gemini

https://www.youtube.com/embed/00g64yDMamw
[This is an embedded link, but you cannot view embedded content directly on the site because you have declined the cookies necessary to access it. To view embedded content, you would need to accept all cookies in your Cookies Settings]

The command doesn't know. That's why you need to check the SQLCODE variable.

If SQLCODE  = 0 then the row exists and it was updated. If SQLCODE  = 100 then the row doesn't exist. If it not equal to either then you have a problem.

Example for Embedded SQL:

 &SQL(update WH.Size
   set Height = 1000
 where %ID = 10)
 write SQLCODE

Example for Dynamic SQL:

 SET myquery = "update WH.Size set Height = 1000 where %ID = 10"
 SET tStatement = ##class(%SQL.Statement).%New()
 SET tStatus = tStatement.%Prepare(myquery)
 SET rset = tStatement.%Execute()
 write rset.%SQLCODE

Not sure what you mean by "if the row exists" in regards with insert. The row does not exist, because you're creating it.

I'd say in general, having a structured data with the actual names of fields is much better than "parsing" the text with delimiters. So I would vote for FHIR. Maybe at some point there will be a better way to represent data - and it is OK - and people will switch to it. The main idea - not to make it painful on the developers to rewrite everything!