Accounts from separate Quicken file being created with recent transactions downloaded

Geobrick

(Quicken Premier Windows R35.31 - WIN10 Pro ver-20H2)
I have 2 separate QDF files on different computers to manage completely different accounts (though some are at the same financial institutions). Things have worked fine for years.

Recently, after a One Step Update, accounts from one qdf file are showing up in the other file along with some recent transactions ready to be reviewed and accepted. The registers are empty but the recent transactions are real.

This seems like a possible crossover of credentials between the two files. The login credentials for the accounts in one file are completely different than for the accounts in the other file. Since I manage both quicken files, there's no real security issue here but there is some data file corruption. I shouldn't be able to access within a file to accounts that were never created or setup for online transactions in that file.

How is this suddenly happening?

The password vault has what seems to be credentials for accounts that were never set up in the file? Each separate qdf file is on a different computers. The only thing in common is my Quicken ID. Is this happening at the server level? I don't sync my files for online or app usage.

Is anyone else experiencing this weirdness?

Geobrick

Maybe there's a mess up with the new way quicken stores credentials for express web connect. "your encrypted credentials are stored with our aggregation provider". Maybe the aggregation provider assumes I have a single quicken file associated with my quicken ID and provides all the credentials for a OSU without distinguishing which accounts are associated with the specific qdf file.

Whatever it is, it's not proper behavior.

Sherlock

I suggest you make certain each of the Quicken files is uniquely identified by using the new Copy File.  Note: You will need to reestablish the Online Services for the new files: select File > Copy or Backup File...

Tom Young

As @Sherlock alluded to, this sort of "cross-file" corruption can occur if the second file was created - sometime in the past before Release 34.xx - by copying the first file and then modifying that copied file for use as the second file.  In this case the two files have the same dataset id and transactions for one of the files can end up in the other file.

Using the "Create a copy or a template" option to create the second file gives that second file a new dataset id, making the two files distinct and eliminating the problem of cross-talk. 

Geobrick

> @Sherlock said:
> I suggest you make certain each of the Quicken files is uniquely identified by using the new Copy File.  Note: You will need to reestablish the Online Services for the new files: select File > Copy or Backup File...

I've done something similar so I'll see what happens. The files always had different names so I did a backup (not copy but I can restore then do a copy later). I renamed the files then deleted the accounts and transactions from from the accounts that didn't belong. I verified the accounts were no longer listed in the password vault or the one step update list. I'll wait a few days to try a one step update and see what happens. Before I did this, accounts that didn't belong from the other file were in the password vault (saying "password not required").

Geobrick

> @Tom Young said:
> As @Sherlock alluded to, this sort of "cross-file" corruption can occur if the second file was created - sometime in the past before Release 34.xx - by copying the first file and then modifying that copied file for use as the second file.  In this case the two files have the same dataset id and transactions for one of the files can end up in the other file.  Using the "Create a copy or a template" option to create the second file gives that second file a new dataset id, making the two files distinct and eliminating the problem of cross-talk. 

Yes the 2nd file was originally split off from the original file 5 years ago. Interesting that it hasn't become a problem until now. I don't often update the 2nd file (6 months ago would have been the last time before a few days ago when this problem showed up).

I'll do the copy for the 2nd file to get a separate data set ID. Thanks Sherlock and Tom.

Sherlock

Geobrick said:

> @Sherlock said:
> I suggest you make certain each of the Quicken files is uniquely identified by using the new Copy File.  Note: You will need to reestablish the Online Services for the new files: select File > Copy or Backup File...

I've done something similar so I'll see what happens. The files always had different names so I did a backup (not copy but I can restore then do a copy later). I renamed the files then deleted the accounts and transactions from from the accounts that didn't belong. I verified the accounts were no longer listed in the password vault or the one step update list. I'll wait a few days to try a one step update and see what happens. Before I did this, accounts that didn't belong from the other file were in the password vault (saying "password not required").

That is not something similar.  Previously, the only way we could create a Quicken file with a unique internal file identifier was to use File > New Quicken File...

In R34.13, the Copy File was finally changed to produce a unique internal file identifier in the new Quicken file: https://www.quicken.com/support/quicken-windows-release-notes

Tom Young

Geobrick said:

Yes the 2nd file was originally split off from the original file 5 years ago. Interesting that it hasn't become a problem until now.

Fairly recent changes on Quicken's end created the problem.  All files now have a "cloud account" associated with them, even if you don't use Quicken mobile or Quicken on the web, and because your two files were associated with one cloud account due to both using the same dataset id, "stuff" happens.