Large balance deviations from bank in MSMoney data files

The batch file has several logic and robustness issues that can easily lead to using the wrong copy of the Money file and cause the large balance deviations being seen.

Key problems in the script:

1. Unreliable time comparison

• The script compares file timestamps as strings:

    for %%A in ("%MasterFile%") do set "MasterTime=%%~tA"
    for %%B in ("%LocalFile%") do set "LocalTime=%%~tB"
    if "%MasterTime%" GTR "%LocalTime%" (
  

• %%~tA returns a localized date/time string (e.g., 4/18/2026 9:05 AM). String comparison with GTR is not reliable across different date formats, 12/24‑hour times, or single‑digit days/months.
• Result: the script may incorrectly decide that the master is older when it is actually newer (or vice versa), so the wrong file becomes the “authoritative” one.

2. Use of %~dpMasterFile% is invalid

• "%~dpMasterFile%" only works on parameters like %1, not on environment variables.
• In this script, %~dpMasterFile% expands to an empty string, so robocopy effectively runs with a blank source directory:

    robocopy "%~dpMasterFile%" "%LocalDir%" "dkwebb.mny" ...
  

• Depending on how cmd parses this, robocopy may:
  • Fail silently (no copy actually happens), or
  • Use the current directory as source.
• That means the working file might not be updated from the external drive at all, or might be overwritten from the wrong location.

3. No error checking on robocopy

• robocopy returns exit codes that indicate success, partial success, or failure.
• The script ignores these codes and always continues as if the copy worked.
• If the external drive is missing, goes to sleep, or has I/O errors, the script may:
  • Leave an old working file in place, or
  • Fail to copy changes back to the master.
• Over time, this leads to divergence between the two copies.

4. Race conditions and multiple runs

• The script assumes:
  • Only one instance runs at a time.
  • Money is always closed before the final robocopy back to master.
• If the script is started twice, or Money is still flushing data when the script copies back, the master can be overwritten with a partially updated or stale file.

5. No protection against direct edits on the master

• If Money is ever opened directly on H:\...\dkwebb.mny (bypassing the script), changes there may be overwritten by the next script run, depending on the timestamp comparison.

6. No backup/rotation

• The script overwrites the master with the working copy every time without keeping any previous versions.
• Any corruption or bad state in the working file is immediately propagated to the master, with no way to roll back.

How to fix the approach (conceptually):

1. Fix path handling

• Replace %~dpMasterFile% with a proper source directory variable:

    set "MasterDir=H:\files\personal\money"
    set "MasterFile=%MasterDir%\dkwebb.mny"
  

  Then use "%MasterDir%" as the robocopy source.

2. Avoid string‑based time comparison

• Either:
  • Always treat the external file as the master and copy it down unconditionally at start, or
  • Use a more robust comparison method (for example, a PowerShell helper that compares LastWriteTime as a DateTime, not as a string).

3. Check robocopy exit codes

• After each robocopy, check %ERRORLEVEL% and abort with a clear message if the copy failed instead of silently continuing.

4. Enforce single‑instance and close‑before‑sync

• Use a simple lock file or check for a running msmoney.exe process before copying back.

5. Add backups

• Before overwriting the master, copy it to a dated backup file on the external drive so there is a recovery point if balances go wrong.

Given that large deviations are already appearing, the data file is likely out of sync or partially corrupted. The safest next steps are:

• Identify the most recent known‑good .mny file (from backups, old copies, or the external drive).
• Stop using the current script until it is corrected.
• Restore from the known‑good file and then adopt a simpler, safer workflow (for example, keep the master only on the local drive and back it up to the external device, not the other way around).

References:

• Basic echo example