[SOLVED] Why no date on last download for Web Connect F/Is?

Direct Connect and Web Connect are significantly different download types - not sure we should expect them to be treated exactly the same everywhere.

Quicken plays an important role in both Direct Connect and Express Web Connect downloads: Quicken initiates the download by sending a request to the financial institution to "send" (download) all eligible transactions. Quicken then processes the downloaded data ... without any option to have that data saved to a file, then imported to Quicken.

And in my case, all my Direct Connect and Express Web Connect accounts display the "Last downloaded ...." date, in the register and in the Account List, following a successful download to the account.

I do not have any accounts that utilize Web Connect normally, but when I do import a Web Connect file to a Quicken account, the "Last downloaded ...." date is not updated, in either the register or the Account List. That's regardless of whether the account is activated for Direct Connect or Express Web Connect ... or just activated for Web Connect. That is: I can import a Web Connect file to an account activated for Direct Connect, Express Web Connect, or Web Connect; but in no case does that import change the "Last updated ...." date.

I searched in Quicken Help and the Quicken online Knowledge Base and did not find anything on the subject of the "Last downloaded" date.

So I can only guess: Quicken plays no part in "Web Connect" downloads; they are 100% between the user and the financial institution. Quicken only enters the picture when the data that has already been downloaded is "imported" into Quicken. So perhaps Quicken is holding to a strict definition of "downloaded" which does not include Web Connect "imports", when it does not update the "Last downloaded ...." date after a Web Connect import. [It's by no means conclusive, but Quicken also does not update the "Last downloaded ...." date after a QIF file has been "imported" into a Quicken account.]

The "Last downloaded" date appears to be pulled from the runtime.dat file maintained in a Quicken file specific folder within the hidden \ProgramData\Quicken\Inet folder.  If you're not seeing the appropriate information, I suggest you exit Quicken, rename, move, or delete the runtime.dat file for the Quicken file, open Quicken, view the One Step Update Summary to verify you manipulated the appropriate runtime.dat file, then perform the downloads.

Note: We do not have any accounts using the Express Web Connect connection method but all my Web Connect and Direct Connect enabled account registers do display the "Last downloaded" date in the register and on the Account List.

If you tried Sherlock's suggestion and are still experiencing your problem, here is a Community discussion on the subject, in which one poster (qcs2u) appears to have a fix for the problem:

Note: it appears that poster qcs2u also utilized Sherlock's suggestion, but did considerably more too. I have no idea whether all steps that qcs2u took were necessary; but if you're unable to fix the problem, I doubt it can hurt to try those steps (backup first).

[Beware there is also quite a bit of b.s. from other posters in that discussion, including the flat-out false statement by the original poster (in a later post) that, " ... you cannot get your history via a QIF file for investment accounts". You most certainly can export/import a QIF file to bring investment transactions from one file to another. ]

Sherlock and John - THANK YOU both, as always, for insightful post. [ [ John, it really wasn't a 'problem', more of an 'annoyance' :-) ]

So I did the procedure that Sherlock had suggested, and indeed it worked and is fine this morning. Both types of accounts now list in the account list with update dates.

But I also have additional insight as to why this was an 'annoyance' to start with.

I update Quicken both from my PC at home, as well as my laptop when traveling. To sync the data files, I copy the entire data directory into DROPBOX after closing Q, then reload it on the other device before loading Q. (I also encrypt/decrypt a copy of the directory before and after the upload/download as well so DROPBOX doesn't have a readable copy of their server)

I did not realize that the file that Sherlock identified to reset lives in a totally different directory structure (under PROGDATA I believe it was) and thus it wasn't getting copied to and fro. So now I understand why this was happening.

I guess my thought is (and this is rhetorical, really) should I ALSO copy this other file as well (that would be a pain and other than this issue, I don't see any ill effects not to do so)....this procedure has worked for me for years without any (other than this) data integrity issue that I've ever experienced.

Make batches to do what you want (Desktop_to_DropBox.bat DropBox_to_ Laptop.bat and reverse) and place on the correct PCs. If you want to zip with password before uploading to DropBox then use 7Zip command line and manually add a password during the batch run. Using batch files eliminates errors and can include everything you want to transfer.

Thanks for posting back with this: hopefully, it will help others.

I'd go with Zaidy036's suggestion.

FWIW: I think it might be a nice idea if Quicken offered users the option to include Quicken associated files (such as: ProgramData\Quicken\Inet\runtime.dat) in their backups - an option which would probably also need to allow the user to "restore" the backed up associated file(s).

That sounds good to me. I don't know why data that relates to the user is not stored under the user directory structure. I might indeed investigate the copy ideas of Zaidy036. It's been a long time since I did command line work.

As mentioned, up to this point, I've never experienced any issue with my backup/restore procedure. I just open the data directory, highlight all the changed files in data order, and use the context sensitive 7ip panel that comes up to ADD TO ARCHIVE and specify the directory in my DROPBOX folder. And visa-versa on the restore. (The source and target structures are even saved in the dropdown file specification on the panel.)

I have nothing to add to this thread but I was intrigued by the files found in the root folder C:\ProgramData\Quicken and its subfolders, and horrified to find my email address, my account names, my stock symbols, and more - all in plain text.

Here is an excerpt from the QCS.log ################### Friday, January 22, 2021, 17:35:52 ##################### VERBOSE:HTTP Request = Get Request:

DatasetId: a-17-digit-string-in-plain-text UserId:my-email-address-in-plain-text

These should all be by-reference to items that are held in secret or at least obfuscated in the QDF file.

I don't understand your concern about the names of your Quicken accounts (totally meaningless to anyone else - even the names of your financial institutions should be meaningless to others) and your "stock symbols" (what difference does it make if someone knows you "might" own shares of some specific security?).

I can not speak for others but the names of my accounts do reflect the real names of the institutions; i.e., I have not intentionally encoded them so they would not be recognizable by a passing observer. That in concert with my email address and stock symbols provides a sophisticated hacker with enough information to begin peeling back the layers of security. I have a feeling you already know this but think the threat is not substantial. Given those hints and a bit of social engineering might well be enough for someone to compromise my accounts. I believe the threat assessment is low but can be substantially reduced by better (coding) practices. Just my two cents. Stay well.

I'm comfortable believing that someone else knowing the names of my financial institutions and the names of the securities I own does not constitute a security risk. But I expect everyone to make their own risk evaluation.