Recent content by George Potemkin

Bingo! DELETE OBJECT ophDataSet. END PROCEDURE. /* Callee */ Tested: a caller gets all records from ophDataSet and then a callee deletes the dataset Thank you!

I was wrong. On return to the editor, Progress deletes all temp-tables linked to the orphaned datasets but it just forgets to delete the datasets themselves. EMPTY-DATASET does crash a session when dataset does not have the temp-tables. The workaround does work! In the callee I’m using...

Unfortunately, it turned out to be impossible to re-use or to delete the "forgotten" datasets from the chain in SESSION:FIRST-DATASET. DELETE OBJECT hDataset has no effect. hDataset:EMPTY-DATASET() crashes a session whatever I do with dataset before EMPTY-DATASET. IMHO, it looks like a bug...

PROCEDURE B: DEFINE OUTPUT PARAMETER DATASET-HANDLE ophDataSet. <code> END PROCEDURE. /* B */ It looks like a dataset is sent to a calling procedure at the END operator. We should not empty a dataset before the END. We can't empty a dataset after the END.

Can it be used to call a remote procedure? Demo.p calls a local procedure only because it's a demo.

# Breakpoint Datasets Buffers 1 Test is beginning... 0 0 2 A: Before OUTPUT DATASET-HANI 0 0 3 B: Before CREATE TEMP-TABLE 0 0 4 B: After CREATE TEMP-TABLE 0 0 5 B: Before CREATE DATASET 0 1 6 B: After CREATE DATASET 1 1...

Documentation says: https://docs.progress.com/bundle/openedge-prodatasets-guided-journey/page/Cleanup-after-using-a-dataset.html There are two recommended practices for cleaning up after using datasets in your code: DETACH-DATA-SOURCE EMPTY-DATASET IMHO, it’s true only partially. I wrote...

The link is back: https://cloud.mail.ru/public/GFD8/YjTxQ5PtZ

I totally agree with Rob but a few questions are still remained. The most of the times I see the voluntaristic choice of the options and I’m trying to collect the criteria to make the choice more “calculable”. I'm looking for a "formula". Let’s assure we should keep the replication running...

https://cloud.mail.ru/public/KHAm/3Qm87siCu It's the 9.1B.rar file - 67.2MB. Let me know when I can remove the file.

What would experts say about the optimal number of variable-length AI extents? 3 is the minimum. What is the best practice? About (or less than) 1 MB/sec (less than 1 GB per 16 min) -> 300 GB of disc space will give you 3.5 days to fix an issue. Great!

I hope your database does not have 300 AI extents of 1 GB size . It's a good idea. You can add the AI extents online. V12.8 prostrct removeonline can remove online only data extents: Unrecognized extent type sports.a3 for prostrct removeonline utility

I can share the documentation for Progress V9.1B if you need it. It's in the pdf format; You can find the installed licenses that will tell you what you can do with a database: %DLC%\bin\showfcfg.exe %DLC%\progress.cfg; You can check a database log (dbname.lg file) to find out how database is...

If we stay with D&L… There are the reasons not to use the multi-threaded load. The load will be the longest phase. Then the best choice, IMHO, is to dump and load in parallel using the multi-volume dump. Bonus - we will use the less disc space.

Max number of the dump threads is defined by the number of the keys in the root block of the index used for dump. In other words, the number of dump threads depends on the chosen index. The larger table more likely its root blocks have just the small numbers of index keys. Dbanalys does not...