Is it normal for a Data File "Backup" followed by a "Restore" to cause Download Error Code CC-800?

JimW VT

Is the current implementation of Quicken Deluxe for Windows setup such that if I do a “Backup” of my Quicken Data File, and then follow that ”Backup” a little while later, with a “Restore” of the same Data File, I will have to reconnect ‘all’ of my Quicken Bank and Credit Card accounts that use “Express Web Connect” with their respective Bank and Credit Card companies, before I can download new transaction information?

I am using Version R61.21 Build 27.1.61.21 of Quicken Deluxe for Windows

My current situation is that if I don’t do the reconnect, I will receive error code CC-800 for ‘all’ of the Bank and Credit Card companies that I try to do an “Express Web Connect” download from. This has happened two out of two times recently. Regular downloads, not preceded by a Restore”, always work fine. Please note that I currently do “Express Web Connect” downloads from six different financial institutions (one Bank and five Credit Card companies). This problem occurs with ‘all’ of them, every time, after I do a “Restore”. The one “Direct Connect” download that I do, does not have this problem, and works fine.

In the past, I was able to do a “Backup”, then “Download” new transaction data, then check to see if my “Renaming Rules” had all worked correctly, and if any had not worked, I could “Restore” the recently backed up data file, fix/add the “Renaming Rule”, and then repeat my previous “Download” to successfully receive the properly renamed transactions.

I would like to be able to continue using the above described “Renaming Rule” verification method, but if I have to do a very time consuming reconnect of six separate accounts every time, it will be impractical for me to continue doing that.

Chris_QPW

None of this is affected by the file name or the folder that it is in. So, you can move it around and rename it as you like. And yes, replace the original data file with the copy if want it instead.

Chris_QPW

Well, I will say this, that "Restore" has gotten "dangerous" over time.

Note it isn't the "Backup" it is the "Restore".

If one was to do a backup and then rename the *.QDF-backup file to *.QDF and then open it, Quicken nothing would be affected.

On the other hand, for quite a while now Restore "Syncs the Cloud account data". Whether people realize it or not Express Web Connect transactions are always stored in the Quicken Cloud account. That is how they now get to Quicken. As in Financial institution to Intuit server to Quicken Cloud account, and then a "sync to the Quicken Desktop data file".

In theory this sync shouldn't have caused the problems you are seeing, that sounds like a bug. But as you seen if things don't go to plan, strange things can happen.

And I might add that even if we take Restore out of the picture, there are "risks" to using an old data file for testing the renaming rules.

Since essentially part of your data is in the Quicken Desktop data file, and part of it is in the Quicken Cloud dataset/account, if they get too far out of sync strange things can start happening.

I don't use Quicken's backup/restore system. I have my own system to get a copy of my data file from any time I want. As such I used to use this to test different problems that people might have had on here. I have stopped doing that because I quickly found that going too far back caused these kinds of problems. I do occasionally do the "renaming rule testing" like you describe, and as long as it say "go back just a few days" that seems to work OK.

JimW VT

Questions to Chris_QPW:

• In the third sentence of your above response, what do you mean by 'Quicken nothing would be affected.'

• In my Quicken program, under 'Edit - Preferences - Mobile & Web', I have Sync set to OFF. Could that cause my problem?

Chris_QPW

To explain the "nothing would be affected" let me give you slightly different example.

Say I use Windows File Explorer and make a copy of my data file. And now I open it and start to use it. As far as Quicken is concerned that data file would be identical to the original copy, it doesn't care about the external file name.

The problems start when things start changing. I don't think it would be any surprise that if in copy you deactivated an account for downloading and then go back to the original data file there are going to be a bit of a problem. As far as the original data file is concerned that account is still active, but if the copy of the data file informed the Quicken Cloud dataset of that deactivation, then it isn't going to consider it active and give errors when you try to do a One Step Update from the original data file.

The point here is that the Quicken Desktop data file isn't completely independent anymore when it comes to the online services.

I hope this makes it a bit clearer.

One the second question. No, turning off that option will not cause this problem, in fact having it off probably will lessen the chances of problems.

Sync to Mobile & Web Tells Quicken to sync the accounts you have selected to the Quicken Cloud dataset, plus all of your memorized payee, renaming rules and budget. Whereas the data that is synced when using Express Web Connect is whatever transactions are downloaded.

Note on the original question, for me the farther back I as far as a copy of my data file the more likely the chance that I will have to reauthorize my Express Web Connect + accounts. I don't use Restore at all because I want to avoid extra data, I think it syncs, but neither a copy nor the Restore is without some risk that you might have to reauthorize

If Quicken Restore/sync was perfect then it would have been the best choice, but it has proven not to be the case. It is an extremely hard thing to get a sync like this to be perfect. Imagine this "Restore case". Over a year, I add accounts, download transactions and such, maybe even remove some accounts, and then I decide to restore to a backup from a year ago. The "Quicken Cloud dataset" doesn't have an "history" that it can pull back that matches your data file from a year ago. It has to somehow make sense out syncing the two together. And the "best way" might be "throw away the Quicken Cloud dataset" and start completely over. Clearly if that is the step they take, then it has lost any "authorization" it might know about.

mjonis

IMO, it's "normal", but shouldn't be happening. I believe every single time I've ever restored from a backup (I backup every day, so the restore has always been to the previous backup for me), it's ALWAYS caused a CC-800 error.

BK

I second the prior comment as well as the details @Chris_QPW wrote.

I create a backup of my data file after every use. I rarely have to restore from a backup, maybe 2-4 times per year. Every time I had to do so, I pretty much restored from the prior use/day, because I did something to my data file that was too time consuming to undo. With that, I still get the CC-800 error in one or two accounts out of 13.

Up until a couple of years ago the restore process was flawless without errors for me but that is no longer the case.

In my Quicken program, under 'Edit - Preferences - Mobile & Web', I have Sync set to OFF. Could that cause my problem?

As far as the question about keeping the "Sync" option OFF, that is the best thing a user can do. From my personal experience and experts on this community which you can search for, enabling Sync may cause data irregularities not worth the convenience of accessing your data on the Web or a mobile device.

Chris_QPW

https://community.quicken.com/discussion/comment/20480449#Comment_20480449

If I had to guess, I would think that for most people it would 100% of the time no matter if they used Restore or a copy of their backup. With Restore, it might even be 100% no matter what. I think I might do a few tests on that.

The reason for this guess is time/changes even for just a copy of your data file is because normally if one is doing this operation, it is because something has gone wrong. And as such some amount of time/changes have happened. Therefore, triggering the "syncing" to basically start over.

JimW VT

More Questions to Chris_QPW:

I think you told me a better way to verify my “Renaming Rules”, but I would like to re-state what I think I can do, in my own words, to make sure that I didn’t miss-understand or just plain miss something. Here is what I think:

I can make a ‘copy’ of my original/main Qdata file from the Quicken folder, and temporarily put it in some other Windows folder (that way I can keep the same QData file name). I can then do a “One Step Update” into my original/main QData file, then check to see if my “Renaming Rule(s)” had worked correctly. If any had not worked,* I could ‘move’ the previously copied Qdata file back into the Quicken folder to replace the original/main Qdata file,** then fix the “Renaming Rule(s)”in the returned Qdata file, and then do another “One Step Update” to successfully receive the properly renamed transactions. Project complete.

* I would need to ‘Exit’ the Quicken program here.

** After doing the ‘move’, I would need to restart the Quicken program.

Chris_QPW

OK, did a restore (to a copy not on top of original). And the first thing I notice is it is asking me to login with my Quicken Id, which is something I almost never have to do. This is already an indication to me that the restored file isn't identical to the one I backed up.

Did a One Step Update, and it put up a message that it was syncing with the Quicken Cloud. And then get this, no errors, but no transactions either. There is a "caching" that happens between the Quicken Desktop and the Quicken Cloud where you can't download new transactions for "some amount of time" because basically they don't even check for new transactions. You can usually tell this because it comes back really fast.

I ran One Step Update, and it is taking time now, so maybe it got the message.

OK, results. Transacitons downloaded, no errors, but I'm seeing "more transactions".

The "more transactions" seem to be harmless. They are in my investment accounts, and no actual transactions downloaded, just a flag that there were transactions. I see this when I make some trades with Chase. I get the real transactions when the I do the buy/sell, and then later when the transactions close, I get this kind of flag. What is happening is the "summary information" for the securities is getting updated as the cash moves between different securities that Chase uses for "cash".

So, this time even Restore "did the right thing".

For me though I will still continue to use may backup/copy of the original data file and not use Restore. Why?

Because I have seen the occasional report that Restore has damaged someone's data file. I see no reason to take the extra chance.

But this testing does tell me that Restore doesn't 100% wipe out the authorization, it has more to do with the Quicken Desktop data file and the Quicken Cloud dataset getting to a stage where they decide that is needed.

Chris_QPW

https://community.quicken.com/discussion/comment/20480506#Comment_20480506

Yes, this is basically the procedure I use when I want to test my renaming rules. But with this extra testing I have done with Restore, I might have just got lucky. So, I think I would only use this procedure for "troubleshooting", which is exactly what I have always used it for. In other words, I don't use this procedure every time I add new renaming rules. I just expect them to work. It is only when I find one not working right do I this kind of testing. And that lowers the chance that you will be doing the reauthorization. But as this discussion has sort proved, there isn't a 100% chance that you won't have to reauthorize.

Chris_QPW

I switched back to my original data file and got duplicate transactions in my investment accounts. Not too hard to clean up, but this points to the nature of what this is all fighting. When you have data stored in multiple locations that all has to stay in sync it is an extremely hard thing to do.

JimW VT

ToChris_QPW:

In an earlier comment, you said:

‘If one was to do a backup and then rename the *.QDF-backup file to *.QDF and then open it, Quicken nothing would be affected.’

My question is: If this backup and rename is done to/in a non-Quicken folder, would that .QDF file be the same as if the person had done a Windows type copy of the original/main QData file? If yes, could that backed-up and renamed file be moved back into the Quicken folder to replace the original/main Qdata file after a “One Step Update” had been done to the original/main QData file?

Chris_QPW

None of this is affected by the file name or the folder that it is in. So, you can move it around and rename it as you like. And yes, replace the original data file with the copy if want it instead.

JimW VT

To Chris_QPW:

I want to thank you for all of the guidance that you shared with me these last few days. I used many of your suggestions to be able to safely do a “One Step Update” into my original QData file, then check to see if my “Renaming Rules” had worked correctly. If any had not worked correctly, I ‘moved’ a previously saved copy of the Qdata file into the Quicken folder to replace the original Qdata file, then fixed the non-working “Renaming Rules” in the new Qdata file, and then did another “One Step Update” to successfully receive the properly renamed transactions.

I did this several times (at least three), and everything worked perfect each and every time. You taught me things that I did not know how to do, and wouldn’t dare to try on my own. You gave me the courage to try, and everything turned out fine. All I can say is: Thank you, Thank you, Thank you.

Very Sincerely,

JimW VT

Chris_QPW

You very welcome, I'm glad I could help.