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).

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 -

• Online Learning -
  • Managing Disk Space
  • Monitoring Message Volume and Disk Space in HealthShare
• Documentation -
  • Monitor Disk Space
  • Journaling Operation Tasks
• Community -
  • Available Space in DB
  • What is causing the journals to grow rapidly

Hope this helps.

Adding to the content @Steve Pisani mentioned I believe this course added lately should be helpful:

Transforming Data into the HL7 FHIR Format

Really enjoyed the webinar @Ron Sweeney

Great content, insights and results, and thanks for the mentions 

Thanks Jeff!

This is an important update for our customers -

On one hand making them aware they now also have the CD releases as non-container kits, while on the other hand reminding them regarding the limitations of these kind of CD releases.