how to confirm if a file has no errors and address issue of Quicken not being able to access disk?

Pacoinconn

Last Saturday I tried to reconcile a 401k account and received the following message and error message during reconciliation:

"The resulting value is too big. Please enter it as more than one transaction". When I pressed "okay", I received the following error message: "Error accessing disk". After pressing okay, the reconciliation process continued however the reconciliation was off from the actual cash balance by the exact amount of one of the transactions (dated March 22, 2022).

I tried to address these messages by deleting the transaction in question and reentering it. When doing so, I received the same messages. I also tried to enter a smaller amount to enter as more than one transaction. I received the same messages.

I also tried to move the file to another location on my computer (in an attempt to address the "Error accessing disk" message. Unfortunately that didn't work either.

My next step was to validate the file, including rebuilding investment lots. That didn't work...same issues as above. I also tried super-validating....which didn't work either.

I have restored a backup from March 3, 2022. Before doing anything else, I validated the file, including rebuilding investment lots.

Now my questions:

1. How can I be sure that the March 3rd file is not damaged? I've attached an anonymized version of the data log after validation.

2. How do I address the issue of Quicken being unable to access the disk? I've run a disk check on the drive...there are no errors.

I'm using Quicken Premier on Windows 11 running as a Virtual Machine on a MacBook Pro. Quicken, Windows 11, and Monterey 12.4 are all updated.

Thank you in advance for your help.

Jim_Harman

Your data file should be stored on a local hard drive that is not networked, shared, or connected to Google Drive, OneDrive, Dropbox, or any cloud storage system. 

You could try running it on a real Windows machine.

Perhaps someone else can comment on the implications for a VM running on a Mac. 

Pacoinconn

@Jim_Harman

Thx for the quick reply.
My data file is on a local drive that is not networked, not shared, nor connected to any cloud storage systrem. Fusion is set up so that my Mac can't access the c:\ drive in the Windows VM. While I used to run Quicken on a Windows machine, I switched to Mac about 15 years ago and haven't had any issues with the same file running under a VM on a Mac.

Would appreciate your help in "interpreting" the log file I attached. Based on the results, do you believe that the Quicken file is okay? Thx.

Jim_Harman

Most of the issues in Validation look benign.

It appears to have fixed some investing lots.

I don't know if the dashes in the lot numbers are significant, especially after the colons. You should not have a negative number of lots.

You should investigate the split messages. Sometimes this means the split is in the file but it is off by a few days, but you should make sure there are not 2 splits when there should only be one, or maybe there is no split recorded but you accepted downloaded "Added" transactions. This gets the share count correct but messes with performance and cost basis calculations.

Pacoinconn

@Jim_Harman ,

Thank you for checking the log file. The splits are okay. I never accept "Added" nor "Removed" transactions so that I can have accurate cost basis calculations.

Did you mean the the negative number of lots as in: "Number of Lot Links: - 149"? If so, I perhaps assumed that the "-" was a "dash" and not a negative sign because the other "-"s appear to be "dashes":

Lot Repair Info: ZZZ’Z’s IRA
Number of Lot Links: - 149
Number of Links Fixed - 2
Number of Links Removed - 0

Or am I missing something when you said "dashes in the lot numbers are significant, especially after the colons. You should not have a negative number of lots."?

If the validation file checks out, my only concern is the "Error accessing disk" message. (Other programs on the Windows c:\ drive and the operating system itself are fine. Have run diskcheck on the Windows VM with no errors detected.) Other than try on a Windows PC, would you have any suggestions on how to address this issue? Thx.

Jim_Harman

I said "I don't know if the dashes in the lot numbers are significant ..." I guess we can chalk that up to sloppy programming in formatting the log file.

I would guess that your data file is OK, except for the problem that led to original "Value is too big" error.

What was the transaction type that produced this message? Sometimes that is related to earlier transactions with the same security. For example see this discussion
https://community.quicken.com/discussion/7851640/broker-account-error-message-resulting-value-too-big-enter-as-more-than-one-transaction

Pacoinconn

@Jim_Harman

Transaction was a "Buy" transaction in a broker account. I will check to see if I have the same or similar "sell" transaction for the same security that occurred in the discussion you cited. I don't think I do, however will check and give an update.

Pacoinconn

@Jim_Harman

I don't have the same issue. I have, however, been able to rebuild the Quicken file using the March backup after validating it. Fortunately I was able to add the transaction in question and reconcile the account in question. So all is well. I hope the errors don't crop up again however. Appreciate your assistance, especially letting me know that the file appears fine based on the log file.