Support,

Can you confirm that when the Detail Listing report is generated to either preview, print or Excel Direct that the GLNUM*.* files are not supposed to get locked?

Curious since when the Detail Listing is generated I can not rename any of these files. I would have thought they were read only.

Just want to confirm.

Hi Scott,

These files have the Account Net Changes values and are used for the Detail Listing report. I wouldn't expect data files to be locked (and I can rename the GLPOST file in the midst of printing this report), so on the surface this doesn't make sense.

I presume you are wondering about file locking for a different reason, say for posting or some other multi-user access, rather than actually wanting to rename a data file while someone is in Adagio Ledger and printing a report.

Thanks Support. I purposely haven't posted anything on this yet but it is to the point now something is going wrong at a client site.

They have continually been getting corrupted Ledger data for the past two weeks now and it appears (and I stress appears) that is a user generates the detail listing this locks the files. In the meantime another user posts a Ledger batch, or that same user that generated the listing posts a batch and they get corrupted data.

In theory if these files are locked (and I know this by going out to the DOS prompt and try to rename them I get the access denied message) then when you try to post these files can not get updated and hence corrupted data?

The other issue is these corruptions appear to have coincided with the Ledger V9.3B upgrade yet no other clients are having this issue to my knowledge with the upgrade applied.

We have rebooted the server and workstations thinking this might be part of the problem but it doesn't appear so.

I have attempted on my end rename the GLNUMB*.* files when I generate the Detail Listing and they are in fact locking. Yet when I post on my end integrity comes back clean.

Continuing to investigate but in my mind these files should not be locking.

Sorry a ramble.

Hi John

I am SOOO happy you posted this. I have a client that has been experiencing multiple instances of corrupted GL data since I installed 9.3B (210225) and I also found that I couldn't rename the GLNUMB*.* files. You got further than I did to suggest that the files got mistakenly locked when printing a Detail Listing.

Of course I couldn't replicate this on my computer and in the end I decided to restore 9.3A to see if the problem continues or disappears. So far it has disappeared.

If you could provide Softrak with backups pre-posting and post-posting (corrupted), they and I would appreciate it. They asked me to provide those but I couldn't find a corrupted backup.

Steve

I can confirm that this rename locking doesn't happen in GL9.3A, and I saw this in 93B. I have already written up something for R&D to investigate. Knowing one reason why files are locked is probably all they need - it's pretty likely that if the Net Changes files are locked and unable to be written to, then the corruption would be that the Net Changes amounts would not synch to the Posted Transactions for the period(s) posted to.

Thanks support since when we run data integrity this is an example of the error:

Error: Account [104000 - ] current balance does not match net change record.
Error: Account [104000 - ] next year opening balance does not match current year current balance.
Master / Net Changes ... 2 error(s) found

I am going to suggest (as a pain as it might be) when they are ready to post for both Ledger users exit the system, one log back in check integrity to make sure it passes, then backup then post until this is resolved or we catch something unique to their environment.

Hi Steve,

Well I must admit I have to give you and Bruce the credit here. It was Bruce who put me on the the GLNUMB*.* files since he received an email from you indicating this issue (sorry Bruce cat out of the bag).

I am going bonkers here with this client and never would have got onto the GLNUMB*.* files issue had he not mentioned your email so for that many thanks.

On our end in the office on a standalone workstation as soon as I generate the Detail Listing (Preview, Print or ExcelDirect) these files get locked and only unlock when I exit the Ledger program. But if I stay in when I want it to corrupt the data it doesn't but it seems too fishy to me since the very errors we are getting are to do with the Net Change files.

FWIW the said client, I installed the V9.3B Ledger upgrade on Feb 22nd. It wasn't until March 3rd that this issue started happening. BUT I did load the SP - 210225 on March 1st (to fix the statement group issue) and then all you know what started happening on March 3rd. So I am thinking the service pack might be the culprit not sure.

I will check with the client to make sure I can send Softrak the files before and after but at this point I think they might welcome this.

And I want to be clear Support I am still not sure if this is environmental or upgrade/service pack related but it does seem to coincidental to me FWIW.

Steve/Support,

I have a set of files prior to corruption and post corruption. I have been given the go ahead by the client to upload these two you.

Let me know where to send.

Thanks in advance.

Data can be uploaded to softrak.com/dbr and select Tech Support rather than for Repair.

I did try to do a 2-user scenario where one user was printing the detail listing report, and the other user posted a number of batches. There were no errors and integrity was clean.

So we'll see what the corrupted data will show - if you know what they were doing in between, that would be helpful. Otherwise we'll need to glean what we can from the SDAPPLOG.

Thanks Support. I have gone back and forth on this a "thousand times". Environment vs the update. Every time I think it's one something comes up and makes me think the other.

As to what happened and what they were doing has been a hair pull since they keep telling me they are not doing anything out of the ordinary and this issue seems to have arose when the upgrade (or at least the service pack) was applied.

Since they don't receive an error when posting they only find out about the corruption when the print (surprise) the Detail Listing to Excel Direct when they are reconciling accounts and they discover the error that has happened before "GL Details Missing for period x" is sitting in the Description column for one or more accounts.

They then run Integrity and obviously the error appears as the example above.

FWIW the files that I will upload to you - the good files were clean as of yesterday at noon (according to their IT person). So not exactly sure when the bad files got corrupted but obviously sometime after noon yesterday.

Thanks for looking into.

Thanks in advance Support files have been uploaded.

Hi Scott,

Based on the integrity errors that exist in the 'After' data for 8 particular accounts, I believe the problem to have happened when batch 1028 was posted. It was the first batch posted after the 'Before' data backup was made. I determined this because for the one income statement account that had an error, the difference between the Net changes and the Posted Transactions for period 12 of year 2021 is exactly the amount posted to that account by batch 1028. Another batch 1031 posted about 4 hours later contained that same account and it was included in the Net Changes value.

Prior to retrieving batch 1028 from Payables and posting it, 2 other users, different than the user who retrieved and posted the suspect batch, had printed the Detail listing report earlier in the day. One user printed it twice, both about an hour before batch 1028 was posted. They had closed the GL program prior to batch 1028 posted. The other user had printed the detail listing once, about 10 minutes before batch 1028 was posted. They did not exit Ledger until they did the retrieve and post for the other batch 1031.

This doesn't prove nor disprove anything as to how the integrity errors started. It's interesting that there were a number of other accounts posted to from batch 1028 that do not show any integrity errors.

I will email you offline with more specifics, rather than the forum posting here. We can post a solution when we know more.

R&D indicated to me that they couldn't see any differences in the code between GL 9.3A and 9.3B in regards to the Detail Listing report and file handling. But investigation is still ongoing.

Many thanks for you investigation and effort. Got you email and reviewing.

I am convinced it has something to do with the Detail Listing FWIW. I can replicate the file locking of the GLNUMB*.* files on my end and only when I exit Ledger do they get "released". Unfortunately I can not replicate the data corruption. Not sure who posted from Support yesterday but you could on your end replicate that the GLNUMB*.* files do not lock in V9.3A but do in V9.3B.

Regarding your analysis if the user printed the detail listing 10 minutes prior to 1028 being posted and did not exit the Ledger system my assumption is the GLNUMB*.* files are at that point locked and the issue appears. But why did other accounts post OK? That is the maddening part of this.

I am hoping R & D can find something at least correct the issue of the file locking on those files.

So as a pain in the you know what as it might be for the time being before they post anything in Ledger will have:

1. All users will communicate with each other and exit out of Ledger.
2. One user will go back in and check data integrity.
3. User will backup the Ledger data.
3. User will post the batch.
4. User will re-run data integrity to make sure all OK.
5. User will backup Ledger data again.

Thanks in advance for any further investigation and posts on this issue.

Support their Next fiscal '2022' is open.

Assume this shouldn't make a hill of beans difference but at this point thought I should mention FWIW.

Support using the above procedures for posting batches there were no issues yesterday at said client.

Any word from Development?

Hi Scott,

No sorry, nothing more or new from R&D regarding this. I tried again this morning, and no new information.

Having the next year 2022 shouldn't have any influence over what is happening. Apart from additional DIC errors being reported for the balance sheet reports because the closing balance for 2021 doesn't match the opening balance for 2022.

Good to know that nothing bad happened on Friday. Perhaps that had to do with being extra careful at this time.

I understand the frustration of problems happening 'sometimes', when it seems the same thing is being done in exactly the same way. What has been found so far has been helpful for investigation.

Thanks Support keep me posted.

Hi Scott,

As from my offline reply, R&D found the place where the GLNUMB files were being read by the report but not closed. I've been informed that a service pack will be release as soon as we can with highest priority.

Thanks for your information and your patience thus far.

For others reading this thread, if you print the detail listing report, you should probably close and re-open the Ledger program in order to unlock those data files.

Has the service pack in question been halted for download? GL detailed listing is probably the most used report during this week (fiscal year end for all First Nations and most NFP's)

For everyone reading this thread, we've pinpointed the sequence of steps required to cause the data corruption, so that you can avoid this until a service pack is released that fixes this, which we hope to be this week.

- User A prints the detail listing report (and the GLNUMB data files are not correctly released).
- User B posts one or more batches.
- User A posts one or more batches that have some accounts the same as what user B posted to. It is this step that causes the corruption.

Because the GLNUMB files were not released, it was behaving in the same way like in the old days when Opportunistic Locking was enabled. The posting done by user A was updating the Net Changes files from the starting point of when the report was printed, not from after the batches user B posted.

Thanks for your patience as we work to get the service pack completed and released.

The Ledger 9.3B (2021.03.31) service pack has been released, which fixes this issue. We apologize for the inconvenience and issues that this problem has caused.

Thanks support. Loaded on said client this morning and holding breath.