Indeed it is in the Location Header.

From the related FHIR docs:

The server returns a 201 Created HTTP status code, and SHALL also return a Location header which contains the new Logical Id and Version Id of the created resource version:

  Location: [base]/[type]/[id]/_history/[vid]

where [id] and [vid] are the newly created id and version id for the resource version. The Location header should be as specific as possible - if the server understands versioning, the version is included. If a server does not track versions, the Location header will just contain [base]/[type]/[id]. The Location MAY be an absolute or relative URL.

Hi Mark,

Indeed all you need to do with your class/es is extend it/them from the DeleteHelper class. No need to add your own %OnDelete() method (in fact that might interfere with the method generation).

From your comment I cannot tell clearly enough what exactly did not get deleted (or of course why).

Per your question, in general what you can expect to see, as per the example I provided, is that the %OnDelete method (label) gets generated in the generated routine (INT).

If you want you can elaborate a little further about the full structure of your classes (you mention PathologyResult and FreeTextLine, but then later also Location which is unclear how it is related), and data (you just mention some ID numbers, but not really who's who), including message header info, and what you see when you purge the data (messages).

(if you want you can even share the actual classes, if you would prefer, also privately).

Maybe then I can be of more assistance.

Dmitry, following up on @Eduard Lebedyuk's comment, and even though you seem to say IIS is not the cause, this does "smell" like an IIS-related configuration.

I suggest you look here in the IIS docs, and in this related thread.

This setting enables to provide custom error pages instead of the "raw" downstream original server error (to be friendlier to users, or to possibly hide sensitive error details).

Try turning this setting off and see if this helps (if Apache is also available for example you can attempt testing with it as well to compare results).

Following up on Shawn's response, these resources might also be helpful in the meantime, and perhaps for others -

"See how to use key features of the Healthcare Action Engine to set up real-time alerts for clinicians. In this exercise, you will build decision support, design a notification using a CDS Hooks card, and write a rule to deliver it."

[I believe the same comment Shawn mentioned about being required to be a HealthShare customer in order to access this content is relevant here as well.]

I know I'm late to the game, but a few notes I thought were worth mentioning in the context of the question and the discussion here -

1. Re using $sortbegin/$sortend - if you want to take this approach, there are dedicated methods on all %Persistent objects that do exactly this - %SortBegin() and %SortEnd(). Note you can use this per index (or for all) and you don't have to worry about the name of the global etc. So this should definitely be preferred IMHO.

By the way, if you are interested, you can see that the "behind-the-scenes" of %Populate's Populate() method uses this approach (a little advanced generator code...), as well as %SQLImportMgr's  GenerateImportRoutine() method.

2. I don't know if this is relevant for your case, but also for the benefit of the wider community and other use-cases, when it comes to bulk/batch fast operations, if Java or .Net are relevant, then our XEP (eXtreme Event Processing) framework could be a good option. And there indeed you have control over when to perform the indexing.

3. I know the discussion was geared towards OOP and not SQL (and the SQL %NOINDEX option was mentioned more than once), depending on how the data is arriving, you might want to consider using the latest (SQL-based) LOAD (BULK) DATA capability.

4. Relating back to #2 above, re XEP. Behind the scenes the XEP access uses (in some cases) a server-side %SaveDirect() method. In theory you can use this yourself. Note it does not address the no indexing topic (again you can consider using #1 - %SortBegin() and %SortEnd() for that) but it has some other performance advantages as apposed to a regular %Save() (it also has some limitations...). Note there is quite an amount of "hassle" about "preparing" the data for this method, as it needs to be in the $ListBuild format the class's storage expects (and possibly other data nodes). Therefore it is quite rarely used directly (not via XEP). But if you have high performance needs, it might be worth considering this, and comparing the benefit it could provide you vs. the drawbacks it has.

Hi Ephraim,

There could be several reasons - 2 common ones are database expansion and journal expansion (or both).

Here are some sample good resources to see more about this topic -

Hope this helps.

Working with Yakov on this, we saw that for SCOPE_IDENTITY() to work on the SQL Serve side it needs to be in the same "scope" of the INSERT (for example in the same Stored Procedure), see here for reference.

So what Yakov ended up doing was encapsulating the INSERT and SELECT SCOPE_IDENTITY() into a Stored Procedure which returns the newly inserted Row ID, and call the SP via the Adapter, thus inserting the new record and getting back the new ID.