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

[Andrew]

When performing a OSU, I see that none of my F/Is that are Direct
Connects show up in the "One Step Update Summary". Nor in the list of
accounts (under "Last Download", they all have "Not Available" displayed
in the column. Only "Express Web Connect"s have a date).

Why is this? Sure, there's a difference in the acquisition method, but
does that preclude from obtaining/displaying the date of the last
successful d/l?

"Curious minds want to know."
--
-------------------------------------------------------------
Regards -

- Andrew

[John Pollard]

On Sunday, January 24, 2021 at 11:43:53 AM UTC-6, Andrew wrote:
> When performing a OSU, I see that none of my F/Is that are Direct
> Connects show up in the "One Step Update Summary". Nor in the list of
> accounts (under "Last Download", they all have "Not Available" displayed
> in the column. Only "Express Web Connect"s have a date).
>
> Why is this? Sure, there's a difference in the acquisition method, but
> does that preclude from obtaining/displaying the date of the last
> successful d/l?

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.]

[Sherlock]

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.

[John Pollard]

On Sunday, January 24, 2021 at 11:43:53 AM UTC-6, Andrew wrote:

> When performing a OSU, I see that none of my F/Is that are Direct
> Connects show up in the "One Step Update Summary". Nor in the list of
> accounts (under "Last Download", they all have "Not Available" displayed
> in the column. Only "Express Web Connect"s have a date).

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: https://community.quicken.com/discussion/7884478/has-onestep-update-summary-changed 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. ]

[Andrew]

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.

[Zaidy036]

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.

[John Pollard]

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

> 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.

I'd go with Zaidy036's suggestion.

[John Pollard]

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).

[Andrew]

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.)

[Fred Jacobowitz]

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: https://services.quicken.com/billpresentment/users
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.
https://community.quicken.com/discussion/7882213/encrypt-quicken-file

[John Pollard]

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?).

[Fred Jacobowitz]

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.

[John Pollard]

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.