Cannot make manual additions to early price history for certain (but not all) securities
The offending funds are FMKIX, EFA, SCZ, and RWR.
Comments
-
I should probably add that I have been using quicken since about 1991 but am new to brokerage accounts. -- MegM0
-
Hey MegM,
Sorry to hear that you are unable to manually update the older price history on those holdings.
I added these tickers into my Quicken and was able to update transactions history for 2012
I went into Tools and then the Security List.
I selected one of the holdings mentioned above and selected Update and Edit Price History.
I am using the 2018 version. If the issue was coming from these particular holdings I would most likely see something similar on my end.
Are you going about updating the price history differently?
Have you tried closing and reopening Quicken to see if the values reappear?
-Quicken Tyka~~~***~~~0 -
Thank you Tyka --
Unfortunately, it doesn't matter how I go into price history -- I am unable to record a price for EFA before 1/4/2013 that will show up in the price list (even if I go through the steps of actually entering a new price, and even if transactions older than 1/4/2013 contain a price for the fund). I thought perhaps the automatic download from 2013 to 2018 had downloaded so many prices that my history was "full" for the problematic four securities, but I can enter additional prices for dates more recent than 1/4/2013 -- so there is obviously room for those. Quicken did one more unexpected crash -- again I cannot imagine why that happened, as I was only doing what I am doing all the time (manually entering transactions that are older than what I have been able, over time, to download). I remain quite stumped....0 -
Trial 1 ... Have you validated the file? I would have Quicken copy the file, then validate the copy. File / File Operations ...MegM said:Thank you Tyka --
Unfortunately, it doesn't matter how I go into price history -- I am unable to record a price for EFA before 1/4/2013 that will show up in the price list (even if I go through the steps of actually entering a new price, and even if transactions older than 1/4/2013 contain a price for the fund). I thought perhaps the automatic download from 2013 to 2018 had downloaded so many prices that my history was "full" for the problematic four securities, but I can enter additional prices for dates more recent than 1/4/2013 -- so there is obviously room for those. Quicken did one more unexpected crash -- again I cannot imagine why that happened, as I was only doing what I am doing all the time (manually entering transactions that are older than what I have been able, over time, to download). I remain quite stumped....
Your description sounds to me as if the price history file (a portion of the overall QDF file) has been damaged. The Validate routine may correct something there, but no promises.
Trial 2 ... Choosing any one of the four, edit the security details, change the ticker (something false like EFA-2), choose to copy quotes for old to new, Choose to delete old. Then reverse the process - Change ticker back (to EFA, for example), again copy old to new. Now try your manual price edits. If successful, repeat for the other securities.0 -
Hello Tyka,
These were helpful suggestions but, mysteriously, I am still stuck.
Validation reported no problems with data. (It did identify five transactions i 2016-2018 that I downloaded a week ago as improperly identified as realized gains rather than as purchases or sales. I have not gotten up to 2016 yet so I have not tinkered with these transactions and have no idea how Quicken could single them out or find these different from the other transactions! This is a new problem I will have to deal with later.)
I tried the procedure you suggested for changing ticker symbols and copying price history. I first copied without simultaneously deleting. The new security (EFA2) had the same price history and also refused to let me add a price for an earlier date. Then I tried it again, copying to new EFA2 and deleting old EFA prices simultaneously. That wiped out the price history entirely. But I WAS ABLE now to add a price for 6/8/2012. So at least I know that if the only solution is to wipe out five years of prices and re-enter six years, I CAN do it (I should only need 1-2 prices per month).
Back to the crashing: something made Quicken 2017 crash, though I was just entering other transactions and not working in any of the problematic four securities when the crash happened. could this mean there is a bug in Quicken 2017?
MegM0 -
I am not sure if the protocol permits including additional problems here beyond the initial inquiry about price history, but all of these inquiries are about the same file, and the problems may be related to each other.
When I started working on this file, I imported the first six months of the account from Quicken 2011, filled with transactions I had downloaded in February 2013. As I checked these six months of transactions that I had imported into Quicken 2017 for the first six months, the account was perfect -- cost basis was perfect, and market value of holdings was perfect ("perfect" means that the Quicken data and reports matched the brokerage statements). Then when I got to December 2012, I noticed the button allowing me to download prices, and I (foolishly) clicked on it. THAT is almost certainly the moment when price history, cost basis, and market value went totally haywire. Reports of holdings (market value and cost basis) for each of the six months that had previously been perfect were now wrong when I checked holdings at the end of each of those six months. That's when I discovered the problem entering prices because I was trying to re-enter the now-missing 2012 prices.
But I noticed in the three options in the Validation dialogue box that price history and cost basis information are separate and one can investigate or validate or check either one. (Price history would obviously be prices; I suppose cost basis would be the information about WHICH prices on which dates to use for calculating basis.) So... I tried the "cost basis correction." The program found no data errors and basically gave me a report identical to the one I got earlier from checking price history: just five transactions in 2016-2018 (the very same five) that it didn't like, that I will have to get to latr.
Obviously downloading prices from the web is what made it all go wrong, which suggests I could go back to my last good Quicken 2011 file and start again. But I am not sure I could stand to start over with the original file and hand-enter the two years of entries that I could not download from the brokerage firm. I am really hoping there are other fixes short of going back to zero!
So: do I dare try to start with the original file and import transactions from the damaged file that contain the subsequent five years of transactions? (I have no recent experience importing transactions from one quicken file to another so I could really mess up the procedure.) Or do I need to find the problem I have now before I risk spreading it?
How would I find out what Quicken is using as cost basis information for a particular security?
Meg M0 -
Just my two cents...and certainly it's open to debate here.
But my impression of Quicken is that downloaded quotes do NOT get overwritten by transactions already entered in the Quicken investment register.
So, for example, if I have shares of XYZ and I have a transaction on 5/30/2018 (sell, buy or dividend) and the price per share of that transaction is $10.0562... that will have preference over Quicken downloading the price per share as $10.06.
Also, Quicken only keeps five years of share prices, excluding any transaction share prices. So, if you're downloading prices and you're beyond the five year period, I think Quicken removes those share prices PROVIDED they don't involve a transaction.
Quicken doesn't provide the cost basis of ANY security you own. That is provided by the share price when the transaction is entered, either through downloading the transaction through your financial institution or manually entering the transaction into the register.
And, there have been issues in the past where incorrect prices have been downloaded by Quicken. Zero price or whacked out prices have been downloaded in the past and can be weeded out by looking at the price history graph for the individual security and then going to the Edit Price History and deleting the "bad downloaded" quote. Sometime, that helps as well. Looking for unusual spikes or dips in the price history graph will clue you in to any problems.
So... here's my take... and it may not correct things one bit, but then again, it might.
1 Backup your data file first... preferably to an outside source such as an external drive, USB thumb drive or cloud based drive.
2 Create a Quicken copy of your data file (FILE > Save a Copy As).
3 With that Quicken copy data file, then FILE > FILE OPERATIONS > Validate and Repair > check Rebuild Investing Lots AND Delete investing price history.
See if that helps. Once again, it may or may not. But you've obviously spent some time with this and another 10-15 minutes shouldn't be a disaster for you.
Worse comes to worse, just reopen your original Quicken data file and delete the copy file if it doesn't correct things.0 -
Thank you Lucille -- I appreciate the suggestions! I don't yet know it my downloading of prices for 2013 to 2018 overwrote any existing prices for that period, but it definitely wiped out the prices, including transaction prices (that still show up if I go to the transaction!) for before 1/4/2013. But here's the really odd thing: my downloads of prices for the ten non-problem funds brought in prices from 2008 forward, including prices I don't need since I did not buy any of these fourteen funds until June 2012. So Quicken does not seem to be hostile to prices that are more than five years old with ten of the funds. (And it would be crazy if Quicken did routinely wipe out prices from more than five years earlier, since that would make it mighty hard to do reports and analyses with any accuracy for a fund one has held more than five years.)
But I tried the validation operation that you suggested. It may have been unwise for me to try doing both the rebuild and the deletion simultaneously. But Quicken crashed. When I re-opened the file that had crashed and tried to do a few reports on holdings that I could compare to paper statements, I found that cost basis data had not changed (of course it was already wrong in the file I was experimenting on, but at least the validating procedure had not changed that data), but the market value data was even more wrong than before.
But the plot thickens. I did a holdings report for 7/31/2014 because I had updated the price data for all fourteen securities for that date just last night; so I knew that the pre-validation file had an extensive set of prices from January 2013 to July 2014 that I had manually entered (entries in 2014 are accepted even by my four problem funds). What I found was stunning: most of the price data I had downloaded and also what I had entered manually was gone, but .... 2012 data from transactions for all funds, including for my four problem funds that had been preventing me from entering prices for 2012, were BAAAACK. The cleanup operation removed all or most of the offending downloaded prices and restored (from what secret memory bank I wonder?) the 2012 prices. I have not investigated exhaustively but it looks as if the ONLY prices that survive are from buying and selling transactions: nothing even from monthly dividends each with their own price of the day. None of the prices I manually entered over the past few days survives unless it is linked to a transaction.
Upshot: I could, if desperate, use this method to get back 2012 prices, and then manually re-enter the next 5 years of prices that correspond to transactions (buying, selling, and dividends). That is hellishly time consuming but it might actually work. So I will keep this in reserve.
My next experiment is to repeat this, but this time doing the two validation processes separately (though I have done that before...).
Meg M0 -
a) I would only do the Delete Prices option as a very last resort. Too much of that information is NOT readily recoverable.MegM said:Thank you Lucille -- I appreciate the suggestions! I don't yet know it my downloading of prices for 2013 to 2018 overwrote any existing prices for that period, but it definitely wiped out the prices, including transaction prices (that still show up if I go to the transaction!) for before 1/4/2013. But here's the really odd thing: my downloads of prices for the ten non-problem funds brought in prices from 2008 forward, including prices I don't need since I did not buy any of these fourteen funds until June 2012. So Quicken does not seem to be hostile to prices that are more than five years old with ten of the funds. (And it would be crazy if Quicken did routinely wipe out prices from more than five years earlier, since that would make it mighty hard to do reports and analyses with any accuracy for a fund one has held more than five years.)
But I tried the validation operation that you suggested. It may have been unwise for me to try doing both the rebuild and the deletion simultaneously. But Quicken crashed. When I re-opened the file that had crashed and tried to do a few reports on holdings that I could compare to paper statements, I found that cost basis data had not changed (of course it was already wrong in the file I was experimenting on, but at least the validating procedure had not changed that data), but the market value data was even more wrong than before.
But the plot thickens. I did a holdings report for 7/31/2014 because I had updated the price data for all fourteen securities for that date just last night; so I knew that the pre-validation file had an extensive set of prices from January 2013 to July 2014 that I had manually entered (entries in 2014 are accepted even by my four problem funds). What I found was stunning: most of the price data I had downloaded and also what I had entered manually was gone, but .... 2012 data from transactions for all funds, including for my four problem funds that had been preventing me from entering prices for 2012, were BAAAACK. The cleanup operation removed all or most of the offending downloaded prices and restored (from what secret memory bank I wonder?) the 2012 prices. I have not investigated exhaustively but it looks as if the ONLY prices that survive are from buying and selling transactions: nothing even from monthly dividends each with their own price of the day. None of the prices I manually entered over the past few days survives unless it is linked to a transaction.
Upshot: I could, if desperate, use this method to get back 2012 prices, and then manually re-enter the next 5 years of prices that correspond to transactions (buying, selling, and dividends). That is hellishly time consuming but it might actually work. So I will keep this in reserve.
My next experiment is to repeat this, but this time doing the two validation processes separately (though I have done that before...).
Meg M
b) I posted above a Trial 2 path that I have not seen any follow-up on.
c) There is a prioritization on prices from various sources as to what takes precedence. I've asked to have that info made available again. When rebuilding a price history, the prices from transactions should be candidates to go into the price history file, but not as replacements for downloaded quotes (as best I recall). The rationale would be that you may have bought the security on that date for $X/share but it closed on that date at $Y/share. The $y value as the daily close would take precedence over the transaction-based value.
As I recall, the transaction-based values can fill the price history slots when the account transaction list is recalculated via a Ctrl-Z action on the account transaction list. That set of transaction-based values should include reinvestments as well as straight buys and sells.0 -
Yes, as far as I recall transaction price at $X/share overrides downloaded prices at $Y/share.MegM said:Thank you Lucille -- I appreciate the suggestions! I don't yet know it my downloading of prices for 2013 to 2018 overwrote any existing prices for that period, but it definitely wiped out the prices, including transaction prices (that still show up if I go to the transaction!) for before 1/4/2013. But here's the really odd thing: my downloads of prices for the ten non-problem funds brought in prices from 2008 forward, including prices I don't need since I did not buy any of these fourteen funds until June 2012. So Quicken does not seem to be hostile to prices that are more than five years old with ten of the funds. (And it would be crazy if Quicken did routinely wipe out prices from more than five years earlier, since that would make it mighty hard to do reports and analyses with any accuracy for a fund one has held more than five years.)
But I tried the validation operation that you suggested. It may have been unwise for me to try doing both the rebuild and the deletion simultaneously. But Quicken crashed. When I re-opened the file that had crashed and tried to do a few reports on holdings that I could compare to paper statements, I found that cost basis data had not changed (of course it was already wrong in the file I was experimenting on, but at least the validating procedure had not changed that data), but the market value data was even more wrong than before.
But the plot thickens. I did a holdings report for 7/31/2014 because I had updated the price data for all fourteen securities for that date just last night; so I knew that the pre-validation file had an extensive set of prices from January 2013 to July 2014 that I had manually entered (entries in 2014 are accepted even by my four problem funds). What I found was stunning: most of the price data I had downloaded and also what I had entered manually was gone, but .... 2012 data from transactions for all funds, including for my four problem funds that had been preventing me from entering prices for 2012, were BAAAACK. The cleanup operation removed all or most of the offending downloaded prices and restored (from what secret memory bank I wonder?) the 2012 prices. I have not investigated exhaustively but it looks as if the ONLY prices that survive are from buying and selling transactions: nothing even from monthly dividends each with their own price of the day. None of the prices I manually entered over the past few days survives unless it is linked to a transaction.
Upshot: I could, if desperate, use this method to get back 2012 prices, and then manually re-enter the next 5 years of prices that correspond to transactions (buying, selling, and dividends). That is hellishly time consuming but it might actually work. So I will keep this in reserve.
My next experiment is to repeat this, but this time doing the two validation processes separately (though I have done that before...).
Meg M0 -
@MegM:MegM said:Thank you Lucille -- I appreciate the suggestions! I don't yet know it my downloading of prices for 2013 to 2018 overwrote any existing prices for that period, but it definitely wiped out the prices, including transaction prices (that still show up if I go to the transaction!) for before 1/4/2013. But here's the really odd thing: my downloads of prices for the ten non-problem funds brought in prices from 2008 forward, including prices I don't need since I did not buy any of these fourteen funds until June 2012. So Quicken does not seem to be hostile to prices that are more than five years old with ten of the funds. (And it would be crazy if Quicken did routinely wipe out prices from more than five years earlier, since that would make it mighty hard to do reports and analyses with any accuracy for a fund one has held more than five years.)
But I tried the validation operation that you suggested. It may have been unwise for me to try doing both the rebuild and the deletion simultaneously. But Quicken crashed. When I re-opened the file that had crashed and tried to do a few reports on holdings that I could compare to paper statements, I found that cost basis data had not changed (of course it was already wrong in the file I was experimenting on, but at least the validating procedure had not changed that data), but the market value data was even more wrong than before.
But the plot thickens. I did a holdings report for 7/31/2014 because I had updated the price data for all fourteen securities for that date just last night; so I knew that the pre-validation file had an extensive set of prices from January 2013 to July 2014 that I had manually entered (entries in 2014 are accepted even by my four problem funds). What I found was stunning: most of the price data I had downloaded and also what I had entered manually was gone, but .... 2012 data from transactions for all funds, including for my four problem funds that had been preventing me from entering prices for 2012, were BAAAACK. The cleanup operation removed all or most of the offending downloaded prices and restored (from what secret memory bank I wonder?) the 2012 prices. I have not investigated exhaustively but it looks as if the ONLY prices that survive are from buying and selling transactions: nothing even from monthly dividends each with their own price of the day. None of the prices I manually entered over the past few days survives unless it is linked to a transaction.
Upshot: I could, if desperate, use this method to get back 2012 prices, and then manually re-enter the next 5 years of prices that correspond to transactions (buying, selling, and dividends). That is hellishly time consuming but it might actually work. So I will keep this in reserve.
My next experiment is to repeat this, but this time doing the two validation processes separately (though I have done that before...).
Meg M
If you have a crash during the "validation" process, albeit in Rebuilding Investment Lots and Rebuild Price History, I'm inclined to think that there is some file corruption still in your data.
I'm with you...trying EACH of those processes alone should narrow down which is causing the crash.
Second, if you get a clean run of both processes, how about trying to SuperValidate your data file and see what happens?
Once again, I'm just conjecturing...but you always have your original backup to fall back on in case this gets really mucked up.
@q.lurker:
Deleting the price history and rebuilding it SHOULD bring in the transaction price history...surely. As of now, MegM can't even get prices for transactions that have occurred and are in the register...which certainly seems very odd to me.0 -
@Lucille: No. I stated the opposite. Your "Yes" should be a "No" in that you are stating the the opposite of my position.MegM said:Thank you Lucille -- I appreciate the suggestions! I don't yet know it my downloading of prices for 2013 to 2018 overwrote any existing prices for that period, but it definitely wiped out the prices, including transaction prices (that still show up if I go to the transaction!) for before 1/4/2013. But here's the really odd thing: my downloads of prices for the ten non-problem funds brought in prices from 2008 forward, including prices I don't need since I did not buy any of these fourteen funds until June 2012. So Quicken does not seem to be hostile to prices that are more than five years old with ten of the funds. (And it would be crazy if Quicken did routinely wipe out prices from more than five years earlier, since that would make it mighty hard to do reports and analyses with any accuracy for a fund one has held more than five years.)
But I tried the validation operation that you suggested. It may have been unwise for me to try doing both the rebuild and the deletion simultaneously. But Quicken crashed. When I re-opened the file that had crashed and tried to do a few reports on holdings that I could compare to paper statements, I found that cost basis data had not changed (of course it was already wrong in the file I was experimenting on, but at least the validating procedure had not changed that data), but the market value data was even more wrong than before.
But the plot thickens. I did a holdings report for 7/31/2014 because I had updated the price data for all fourteen securities for that date just last night; so I knew that the pre-validation file had an extensive set of prices from January 2013 to July 2014 that I had manually entered (entries in 2014 are accepted even by my four problem funds). What I found was stunning: most of the price data I had downloaded and also what I had entered manually was gone, but .... 2012 data from transactions for all funds, including for my four problem funds that had been preventing me from entering prices for 2012, were BAAAACK. The cleanup operation removed all or most of the offending downloaded prices and restored (from what secret memory bank I wonder?) the 2012 prices. I have not investigated exhaustively but it looks as if the ONLY prices that survive are from buying and selling transactions: nothing even from monthly dividends each with their own price of the day. None of the prices I manually entered over the past few days survives unless it is linked to a transaction.
Upshot: I could, if desperate, use this method to get back 2012 prices, and then manually re-enter the next 5 years of prices that correspond to transactions (buying, selling, and dividends). That is hellishly time consuming but it might actually work. So I will keep this in reserve.
My next experiment is to repeat this, but this time doing the two validation processes separately (though I have done that before...).
Meg M
While I transaction price will fill in if there is no other price available, I believe if any other price is available, the transaction price will not override that other prices. That is, my position is that the transaction prices is at the lowest end of the precedence list.0 -
MegM said:
Thank you Lucille -- I appreciate the suggestions! I don't yet know it my downloading of prices for 2013 to 2018 overwrote any existing prices for that period, but it definitely wiped out the prices, including transaction prices (that still show up if I go to the transaction!) for before 1/4/2013. But here's the really odd thing: my downloads of prices for the ten non-problem funds brought in prices from 2008 forward, including prices I don't need since I did not buy any of these fourteen funds until June 2012. So Quicken does not seem to be hostile to prices that are more than five years old with ten of the funds. (And it would be crazy if Quicken did routinely wipe out prices from more than five years earlier, since that would make it mighty hard to do reports and analyses with any accuracy for a fund one has held more than five years.)
But I tried the validation operation that you suggested. It may have been unwise for me to try doing both the rebuild and the deletion simultaneously. But Quicken crashed. When I re-opened the file that had crashed and tried to do a few reports on holdings that I could compare to paper statements, I found that cost basis data had not changed (of course it was already wrong in the file I was experimenting on, but at least the validating procedure had not changed that data), but the market value data was even more wrong than before.
But the plot thickens. I did a holdings report for 7/31/2014 because I had updated the price data for all fourteen securities for that date just last night; so I knew that the pre-validation file had an extensive set of prices from January 2013 to July 2014 that I had manually entered (entries in 2014 are accepted even by my four problem funds). What I found was stunning: most of the price data I had downloaded and also what I had entered manually was gone, but .... 2012 data from transactions for all funds, including for my four problem funds that had been preventing me from entering prices for 2012, were BAAAACK. The cleanup operation removed all or most of the offending downloaded prices and restored (from what secret memory bank I wonder?) the 2012 prices. I have not investigated exhaustively but it looks as if the ONLY prices that survive are from buying and selling transactions: nothing even from monthly dividends each with their own price of the day. None of the prices I manually entered over the past few days survives unless it is linked to a transaction.
Upshot: I could, if desperate, use this method to get back 2012 prices, and then manually re-enter the next 5 years of prices that correspond to transactions (buying, selling, and dividends). That is hellishly time consuming but it might actually work. So I will keep this in reserve.
My next experiment is to repeat this, but this time doing the two validation processes separately (though I have done that before...).
Meg MDeleting the price history and rebuilding it SHOULD bring in the transaction price history...surely. As of now, MegM can't even get prices for transactions that have occurred and are in the register...which certainly seems very odd to me.
First off, as I suggested, I have not used the Delete Price History because I consider it only a last resort option. While I acknowledge that they say they will "rebuild the price history" back for five years, I have never seen an explanation for how they do that. The implication to me would be that they do a download of historical prices for the max available period of five years. End of action.
I would speculate that the transaction prices would only get entered if the user did a Crtl-Z recalculation on each account. That set of prices would be developed for the entire period of the account and for every security in the account, not just for 5 years. .0 -
I've used that option before with no terrible effects.MegM said:Thank you Lucille -- I appreciate the suggestions! I don't yet know it my downloading of prices for 2013 to 2018 overwrote any existing prices for that period, but it definitely wiped out the prices, including transaction prices (that still show up if I go to the transaction!) for before 1/4/2013. But here's the really odd thing: my downloads of prices for the ten non-problem funds brought in prices from 2008 forward, including prices I don't need since I did not buy any of these fourteen funds until June 2012. So Quicken does not seem to be hostile to prices that are more than five years old with ten of the funds. (And it would be crazy if Quicken did routinely wipe out prices from more than five years earlier, since that would make it mighty hard to do reports and analyses with any accuracy for a fund one has held more than five years.)
But I tried the validation operation that you suggested. It may have been unwise for me to try doing both the rebuild and the deletion simultaneously. But Quicken crashed. When I re-opened the file that had crashed and tried to do a few reports on holdings that I could compare to paper statements, I found that cost basis data had not changed (of course it was already wrong in the file I was experimenting on, but at least the validating procedure had not changed that data), but the market value data was even more wrong than before.
But the plot thickens. I did a holdings report for 7/31/2014 because I had updated the price data for all fourteen securities for that date just last night; so I knew that the pre-validation file had an extensive set of prices from January 2013 to July 2014 that I had manually entered (entries in 2014 are accepted even by my four problem funds). What I found was stunning: most of the price data I had downloaded and also what I had entered manually was gone, but .... 2012 data from transactions for all funds, including for my four problem funds that had been preventing me from entering prices for 2012, were BAAAACK. The cleanup operation removed all or most of the offending downloaded prices and restored (from what secret memory bank I wonder?) the 2012 prices. I have not investigated exhaustively but it looks as if the ONLY prices that survive are from buying and selling transactions: nothing even from monthly dividends each with their own price of the day. None of the prices I manually entered over the past few days survives unless it is linked to a transaction.
Upshot: I could, if desperate, use this method to get back 2012 prices, and then manually re-enter the next 5 years of prices that correspond to transactions (buying, selling, and dividends). That is hellishly time consuming but it might actually work. So I will keep this in reserve.
My next experiment is to repeat this, but this time doing the two validation processes separately (though I have done that before...).
Meg M
I think using that option certainly can't hurt... but with a previous backup just in case.
At this point, things are going sideways with MegM anyways, so why not try it...if the process doesn't crash.
I still think there's some corrupt record in the account in question.0 -
MegM said:
Thank you Lucille -- I appreciate the suggestions! I don't yet know it my downloading of prices for 2013 to 2018 overwrote any existing prices for that period, but it definitely wiped out the prices, including transaction prices (that still show up if I go to the transaction!) for before 1/4/2013. But here's the really odd thing: my downloads of prices for the ten non-problem funds brought in prices from 2008 forward, including prices I don't need since I did not buy any of these fourteen funds until June 2012. So Quicken does not seem to be hostile to prices that are more than five years old with ten of the funds. (And it would be crazy if Quicken did routinely wipe out prices from more than five years earlier, since that would make it mighty hard to do reports and analyses with any accuracy for a fund one has held more than five years.)
But I tried the validation operation that you suggested. It may have been unwise for me to try doing both the rebuild and the deletion simultaneously. But Quicken crashed. When I re-opened the file that had crashed and tried to do a few reports on holdings that I could compare to paper statements, I found that cost basis data had not changed (of course it was already wrong in the file I was experimenting on, but at least the validating procedure had not changed that data), but the market value data was even more wrong than before.
But the plot thickens. I did a holdings report for 7/31/2014 because I had updated the price data for all fourteen securities for that date just last night; so I knew that the pre-validation file had an extensive set of prices from January 2013 to July 2014 that I had manually entered (entries in 2014 are accepted even by my four problem funds). What I found was stunning: most of the price data I had downloaded and also what I had entered manually was gone, but .... 2012 data from transactions for all funds, including for my four problem funds that had been preventing me from entering prices for 2012, were BAAAACK. The cleanup operation removed all or most of the offending downloaded prices and restored (from what secret memory bank I wonder?) the 2012 prices. I have not investigated exhaustively but it looks as if the ONLY prices that survive are from buying and selling transactions: nothing even from monthly dividends each with their own price of the day. None of the prices I manually entered over the past few days survives unless it is linked to a transaction.
Upshot: I could, if desperate, use this method to get back 2012 prices, and then manually re-enter the next 5 years of prices that correspond to transactions (buying, selling, and dividends). That is hellishly time consuming but it might actually work. So I will keep this in reserve.
My next experiment is to repeat this, but this time doing the two validation processes separately (though I have done that before...).
Meg MI think using that option certainly can't hurt
@Lucille: That is where I disagree. If a user has securities whose history cannot be fully "rebuilt" from the 5-year download of historical data, that user may be in a world of hurt by deleting that non-reproducible data. Those securities would include bonds, private securities, 401k unit trusts, securities that have gone bankrupt (no longer traded), securities that have been acquired (no longer traded), probably options (not my bailiwick), and undoubtedly others. Further, the first four years of that rebuilt data will only be month-end values.
All that may generally be adequate for some users; but as I see it with over 25 years of data in my file, I have a tremendous amount of data at risk of being lost by going the Delete Prices option within the Validate routines.
That being said, there are still some ways to recover some (much?) of that at-risk data. I just don't want to have to jump through those hoops not do I wish that on anyone else.
I now also see further that a response MegM addressed to Tyka included the approach I suggested and seemed to provide positive results when executed as I suggested (with the delete). So I would hold forth that there is a better alternative.
I'll let MegM decide rather than try to hash this out with you on a hypothetical basis.0 -
My goodness, thank you all for such rich suggestions and warnings.MegM said:Thank you Lucille -- I appreciate the suggestions! I don't yet know it my downloading of prices for 2013 to 2018 overwrote any existing prices for that period, but it definitely wiped out the prices, including transaction prices (that still show up if I go to the transaction!) for before 1/4/2013. But here's the really odd thing: my downloads of prices for the ten non-problem funds brought in prices from 2008 forward, including prices I don't need since I did not buy any of these fourteen funds until June 2012. So Quicken does not seem to be hostile to prices that are more than five years old with ten of the funds. (And it would be crazy if Quicken did routinely wipe out prices from more than five years earlier, since that would make it mighty hard to do reports and analyses with any accuracy for a fund one has held more than five years.)
But I tried the validation operation that you suggested. It may have been unwise for me to try doing both the rebuild and the deletion simultaneously. But Quicken crashed. When I re-opened the file that had crashed and tried to do a few reports on holdings that I could compare to paper statements, I found that cost basis data had not changed (of course it was already wrong in the file I was experimenting on, but at least the validating procedure had not changed that data), but the market value data was even more wrong than before.
But the plot thickens. I did a holdings report for 7/31/2014 because I had updated the price data for all fourteen securities for that date just last night; so I knew that the pre-validation file had an extensive set of prices from January 2013 to July 2014 that I had manually entered (entries in 2014 are accepted even by my four problem funds). What I found was stunning: most of the price data I had downloaded and also what I had entered manually was gone, but .... 2012 data from transactions for all funds, including for my four problem funds that had been preventing me from entering prices for 2012, were BAAAACK. The cleanup operation removed all or most of the offending downloaded prices and restored (from what secret memory bank I wonder?) the 2012 prices. I have not investigated exhaustively but it looks as if the ONLY prices that survive are from buying and selling transactions: nothing even from monthly dividends each with their own price of the day. None of the prices I manually entered over the past few days survives unless it is linked to a transaction.
Upshot: I could, if desperate, use this method to get back 2012 prices, and then manually re-enter the next 5 years of prices that correspond to transactions (buying, selling, and dividends). That is hellishly time consuming but it might actually work. So I will keep this in reserve.
My next experiment is to repeat this, but this time doing the two validation processes separately (though I have done that before...).
Meg M
I haven't tried supervalidation yet but will tackle that. At this point (since I am also having strange problems with placeholder entries that Quicken actually has correct data on -- no reason to label them as placeholders with missing information because quicken shows the translations with full and correct details...), I think I have only two courses of action after that: to delete price history and re-enter all price data by hand; or to abandon my downloads into quicken 2017, which ruined everything, and to go back to Quicken 2011 and hand-enter all six years of transactions (a task attractive only to extremists I am sure). I currently do everything in airplane mode so that quicken simply cannot download transactions unless I request that.
Further suggestions most welcome! Does Quicken's incorrect label of placeholder transactions offer up any clues?0 -
A couple of things: I am saving all price histories to PDF so I don't lose them, if I have to hand-enter them later. I agree that something must be profoundly corrupt in my file. There are only two ways this can have happened: either Quicken 2017 mangled my original Quicken 2011 file, or the download of on-line price data caused a problem. Other than that, all I have done is to enter transactions by hand (the ones that are too early to download now).
Apart from sheer loss of time and miserable tedium, is there any reason to worry that building the rest of the file by entering transactions by hand (rather than by downloading transactions) would not provide Quicken with adequate information? I confess that cash sweeping and such perplex me a bit, so I am nervous about relying entirely on manual entry. (But for 27 years I have had many Quicken files, including investment accounts with share values and price histories, that were not brokerage accounts, all built entirely from manual entries, and the results have been just fine. Quicken 2000, 2006, and 2011 have been fine and have never messed me up.)
MegM0 -
MegM said:
A couple of things: I am saving all price histories to PDF so I don't lose them, if I have to hand-enter them later. I agree that something must be profoundly corrupt in my file. There are only two ways this can have happened: either Quicken 2017 mangled my original Quicken 2011 file, or the download of on-line price data caused a problem. Other than that, all I have done is to enter transactions by hand (the ones that are too early to download now).
Apart from sheer loss of time and miserable tedium, is there any reason to worry that building the rest of the file by entering transactions by hand (rather than by downloading transactions) would not provide Quicken with adequate information? I confess that cash sweeping and such perplex me a bit, so I am nervous about relying entirely on manual entry. (But for 27 years I have had many Quicken files, including investment accounts with share values and price histories, that were not brokerage accounts, all built entirely from manual entries, and the results have been just fine. Quicken 2000, 2006, and 2011 have been fine and have never messed me up.)
MegMApart from sheer loss of time and miserable tedium, is there any reason to worry that building the rest of the file by entering transactions by hand ... would not provide Quicken with adequate information? I confess that cash sweeping and such perplex me a bit, so I am nervous about relying entirely on manual entry.
It is understandable to be "nervous" about certain manual entries, but I would examine the other side of the coin as well -- Can you "trust" the brokerage to get all the data right into Quicken the way you want and need it? Just because the brokerage reports a transaction some way, doesn't make it right. That then takes you to the point of need to really understand that transactions - what they represent in both in the real world and in Quicken. Once you have that confidence, you can manage both your "nervousness" and the "trust" in the brokerage.investment accounts with share values and price histories, that were not brokerage accounts
Investment accounts in Quicken are brokerage accounts whether the account is associated with a brokerage (in the program) or is an IRA, 401k, or similar. I think what you are trying to say was that the accounts were not set up to download information from the brokerage to the program. The history of manual entries you cite should give you confidence that manual entries can be fully adequate. QW2017 is no different in that regard. (So says a user who has run various Quicken's since the days of DOS).0 -
Thank you lurker! I am building confidence. I had to fight with quicken to do a share class conversion that had to be hand-entered, and occasionally i find that I enter the wrong security for a transaction (there are a few with almost identical names and I select the wrong one without knowing it). But checking along the way to make sure totals make sense and price history makes sense helps. Looking at price history and finding an insane entry (on one day, share price jumps from 18 to 45 and then goes back the next day to 18?) always turns out to mean that I entered the wrong security for the day with the 45.
This is indeed my first encounter with brokerage accounts (because I have never pulled my 403B into quicken either -- the only investment accounts I have done before were for single mutual funds, which are easy by comparison.0 -
Price History can be exported to a QIF file using the Security selection option. With some effort, the history can be imported into an Excel file and reviewed/cleaned up. From there, the cleaned up version could be imported back into your data file.MegM said:Thank you lurker! I am building confidence. I had to fight with quicken to do a share class conversion that had to be hand-entered, and occasionally i find that I enter the wrong security for a transaction (there are a few with almost identical names and I select the wrong one without knowing it). But checking along the way to make sure totals make sense and price history makes sense helps. Looking at price history and finding an insane entry (on one day, share price jumps from 18 to 45 and then goes back the next day to 18?) always turns out to mean that I entered the wrong security for the day with the 45.
This is indeed my first encounter with brokerage accounts (because I have never pulled my 403B into quicken either -- the only investment accounts I have done before were for single mutual funds, which are easy by comparison.0 -
Thanks Markus. I may have to do this. New experience this evening is alarming. One of these securities does not appear in the Tools/Security List, but the account knows about it and always lists it in Holdings reports. The price history for that security was fine until a few minutes ago when it got almost totally wiped out (about 285 of 300 price entries just disappeared. I figured this out by looking at a holdings report -- I look at holdings after each month's worth of data entry to check for accuracy against the brokerage's paper reports -- and found that this security now had a market value of zero without having been sold. And this WAS one of my "non" problem securities.
I have no idea what file to use to proceed with. I have a backup made a few hours ago that still contains the proper price history for this security, but that backup presumably carries the same time bomb that went off tonight in the otehr file. Should I interpret this to mean that my file and all of its assorted spinoffs and bakcups are fundamentally corrupt and subject to random whimsy beyond my control? Is there a known fixable defect that afflicts price history and price history only? Should I give up and rebuild my file from the original (the one I downloaded in February 2013 into Quicken 2011)?
Best,
MegM0 -
I have also encountered the possibility of deleting a security and re-adding it. I presume I would have to type in the entire price history again if I did that. But would deleting it harm the transactions involving that security? Deleting a price from price history does not alter the price noted in any of the transactions for that security.
Other options are uninstalling Quicken 2017 and reinstalling it. And I must do supervalidation.
But if anybody knows why the program would just wipe out a price history without warning, please let me know. I did not download historical prices. But Windows 10 did do a forced update while this file was open, a few hours before I resumed work on it. These updates do not seem to save the documents that are open when the forced update starts. I have read much on the internet about people losing enormous amounts of data due to a forced W10 update. But losing data is not the same as having the program itself destroy data while the program is running, hours AFTER the forced update.0 -
If you haven't already, you should review the Quicken KB article on repairing damaged data files.MegM said:I have also encountered the possibility of deleting a security and re-adding it. I presume I would have to type in the entire price history again if I did that. But would deleting it harm the transactions involving that security? Deleting a price from price history does not alter the price noted in any of the transactions for that security.
Other options are uninstalling Quicken 2017 and reinstalling it. And I must do supervalidation.
But if anybody knows why the program would just wipe out a price history without warning, please let me know. I did not download historical prices. But Windows 10 did do a forced update while this file was open, a few hours before I resumed work on it. These updates do not seem to save the documents that are open when the forced update starts. I have read much on the internet about people losing enormous amounts of data due to a forced W10 update. But losing data is not the same as having the program itself destroy data while the program is running, hours AFTER the forced update.
https://www.quicken.com/support/advanced-data-file-troubleshooting-correct-problems-quicken-windows0 -
Oh, gosh, it had not occurred to me that Quicken 2011 to Quicken 2017 might be too much of a leap. I would have to spend hours (days) re-entering transactions if I went back to my starter Quicken 2011 file.... Wouldn't Quicken 2017 have reported some trouble during the conversion?MegM said:I have also encountered the possibility of deleting a security and re-adding it. I presume I would have to type in the entire price history again if I did that. But would deleting it harm the transactions involving that security? Deleting a price from price history does not alter the price noted in any of the transactions for that security.
Other options are uninstalling Quicken 2017 and reinstalling it. And I must do supervalidation.
But if anybody knows why the program would just wipe out a price history without warning, please let me know. I did not download historical prices. But Windows 10 did do a forced update while this file was open, a few hours before I resumed work on it. These updates do not seem to save the documents that are open when the forced update starts. I have read much on the internet about people losing enormous amounts of data due to a forced W10 update. But losing data is not the same as having the program itself destroy data while the program is running, hours AFTER the forced update.0 -
Hi everybody.
The problem I just had with a fifth security, IWF, suggests that I cannot fix all of these issues within the file I am now using. Quicken2017 just wiped the price history in IWF from dozens of prices to four prices. If I try to re-enter an additional price for any date prior to the oldest surviving price entry of the four that remain (which means no price for 2012 to 2016 can be added), Quicken will not record that price in the price history. Markus sent me to a link about data problems that result from converting old quicken files to new quicken files without going through intermediate years. This may be my problem -- basically, the quicken 2017 file has been defective from the start. HOWEVER it is amazing to me that Quicken 2017 would go ahead and TRY to convert quicken 2011 if i fact it cannot actually do that safely. Any Quicken version to which one attempts to convert files should perform that conversion only on files from older versions that it CAN safely handle, and otherwise issue a warning popup window refusing to convert files from too early a version of Quicken. I have found no literature on how to convert Quicken 2011 files in particular, let alone what intermediate version of Quicken I would need to use to convert the data safely and smoothly....0 -
MegM said:
Hi everybody.
The problem I just had with a fifth security, IWF, suggests that I cannot fix all of these issues within the file I am now using. Quicken2017 just wiped the price history in IWF from dozens of prices to four prices. If I try to re-enter an additional price for any date prior to the oldest surviving price entry of the four that remain (which means no price for 2012 to 2016 can be added), Quicken will not record that price in the price history. Markus sent me to a link about data problems that result from converting old quicken files to new quicken files without going through intermediate years. This may be my problem -- basically, the quicken 2017 file has been defective from the start. HOWEVER it is amazing to me that Quicken 2017 would go ahead and TRY to convert quicken 2011 if i fact it cannot actually do that safely. Any Quicken version to which one attempts to convert files should perform that conversion only on files from older versions that it CAN safely handle, and otherwise issue a warning popup window refusing to convert files from too early a version of Quicken. I have found no literature on how to convert Quicken 2011 files in particular, let alone what intermediate version of Quicken I would need to use to convert the data safely and smoothly....I have found no literature on how to convert Quicken 2011 files in particular, let alone what intermediate version of Quicken I would need to use to convert the data safely and smoothly....
See this link;
https://www.quicken.com/support/how-and-when-use-intermediate-version-convert-older-versions-quickenQWin & QMac (Deluxe) Subscription
Quicken user since 19910 -
Thanks JM. The link that you and Markus sent doesn't cover Quicken 2011. But while hunting further I found this item, specifically on going from Quicken 2011 to Quicken 2017. (I have Home and Business for both, not Deluxe for both, but I doubt if that matters.)
https://getsatisfaction.com/quickencommunity/topics/updating-quicken-2011-release-r-to-quicken-2017
It is apparently safe if one validates the original file before converting which regrettably I did not do. Darn. I think I need to get used to doing validation and supervalidation with considerable frequency.QuickenUserDC, SuperUser 28,356 Points
Yes, Quicken 2017 Deluxe or higher will convert Quicken 2011 Deluxe.
Some suggestions:
Check your reminders (if any) and delete any that are no longer really wanted. If a reminder needs to be changed, delete the reminder in your previous version and then recreate it after upgrading.
In the same way I would look at your online accounts to see if any should be deleted.
Remove your data file and transaction passwords.
Remove any unneeded memorized payees.
Then, using Quicken (File > File Operations > Copy...), make a copy of your current data file. Quicken will do some file cleanup whereas the Windows copy will make a bit-by-bit copy.
Finally, validate this new data file. If you encounter any errors in the validation, correct and then do the Quicken copy again.
Next, use your current Quicken version to verify that everything is working.
Finally, do the upgrade and add any passwords that you want.
This process helps ensure that you have a good data file going into the upgrade.0 -
This discussion seems to be bouncing all over the place making things somewhat difficult to follow.
Aspects not clear:
a) After your initial crash using QW2017, that clearly damaged the price-history information, it is not clear to me what file you continued forward with.
b) It is not clear to me how "recently" you converted from QW2011 to QW2017
c) It is not clear to me what your history was with QW2011. It appears that you used it into sometime in 2013 but than apparently abandoned use and are now trying to fill in the gap. Is that accurate?
d) It is not clear to me why you are having this repeated issue of lost data. This to me is the most critical issue.
What I would be doing
1) I would be working on a file from before the crash that first damaged the price history data. I would certainly consider going back to the original file after converting to QW2017. I would consider reconverting the last QW2011 data file. But as indicated, I don't know the timings on these aspects. If QW2017 seemed to be fine up until June 1 (when you started this post), I would expect any backup to be OK from before that.
2) As I indicated, why the crashes? My first impulse question is how are you managing your data file? IMO, it should be located on your hard drive in the PC you are running Quicken on. If you are storing and accessing the file on a local network, that can be a problem. If you are working on it through Dropbox or Google Drive or similar, that can be a problem. If you are working it off of a USB flash drive, that could be a problem.
I also recall a post from a user who subsequently identified Quicken file problems as due to a failing hard drive. FWIW.
I would seriously be trying to address the crashes before jumping into too much rebuild and backfill.
3) Validation: The validation routines in QW2017 are undoubtedly better than than the QW2011 versions. Further, I believe upon conversion, the data is run through the current validation routines, though not with the options to delete prices, obviously. So I would not worry so much about missing that step as you exited QW2011. It is still good policy but not a deal breaker in my opinion.
Validation CAN detect problems and give you the best shot at having clean data.
Validation CANNOT detect all problem nor guarantee your data is totally clean.
I do not include validation as a regular step on my data file(s). I don't believe that to be necessary. I believe in your case, there s something else going on beyond the scope of the validation error detection.
4) When you get to the step of rebuilding price data, I would be referencing Yahoo Finance for the 14 mutual funds, downloading their prices as CSV files for the time periods of interest, editing those files to the necessary structure for Quicken, and then importing those data as csv files for each of the 14 funds.
5) As you are working though this and beyond, I would establish a regimented backup policy to make it easy to restore to any particular time point, should a problem develop again.
HTH0 -
Dear Lurker,
You are truly marvelous in being willing to come back and try to sort out this chopped up story.
I have used QW2011 for ALL of my quicken work since 2010 and it has never crashed. It has always seemed very stable. in fact, I have used QW2011 or its predecessors almost daily since about 1991. However, the fanciest thing I have ever done with QW is an investment file that contains separate accounts for single mutual funds, so I have not really tested QW2011 on anything as complex as a multi-fund brokerage account. I installed QW2017 on one machine last week, but solely for the purpose of building this brokerage account with newly downloaded transactions through 2018. All of my other QW files remain in Q2011 and I plan to keep them that way (on the theory that "if it ain't broke, don't fix it"). My Quicken files of all vintages are on my own hard drives (just as you suggest), which are fairly new (1 year old and 2 months old) so quite healthy.
I have been making copies of my problem QW2017 brokerage file periodically as I progress through the process of adding missing transactions by hand, but after both first and second crashes, I foolishly continued working on the same file, rather than a slightly older copy of it. (I didn't want to lose the transactions I had just added by hand, but the first crash happened so FAST that I had not yet made a copy of it.) I have now decided, after the latest crash-and-data-failure, to stop -- as you point out, the data loss is very worrisome, and the crashes signify that something is deeply wrong. In fact, I have returned to the QW2011 original (which I did validate before starting this time, just in case). It is hard (tedious, stupid) work but I have not had a glitch since. Best of all, the added months of data all produce holdings reports that match the paper reports. I validated the QW2011 file before starting to add entries (no errors, but "some transactions were changed," which mystifies me!). I should have done that before launching the QW2017 effort laslt week, but I don't think I did (I had no idea my file was afflicted).
I don't think I can figure out the crashes, which do indeed scare me. So I just took the plunge and returned to QW2011 and the hard slogging of making manual entries (and I check them against the paper reports and make a new backup at the end of every month of additions). When I get up to April 2015 (which is the date beyond which my QW2017 files offer downloaded transactions as a tempting labor-saving device), I plan to experiment with a conversion to QW2017 and importing the transactions from the existing file. Or from a newly downloaded file that I can validate first (but this will lack a year of transactions I will still have to add manually.) But I worry that I will be contaminating my clean file (the QW2011 file that I have to convert to QW2017 to do this) when that, which will drive me back to the clean QW2011 file to continue by hand.
Thank you for your fantastic suggestion about downloading .csv files from Yahoo and the like to get full price history and then editing it in Excel to produce a file I could import as new price history.
And it is valuable for me to keep in mine that QW2017 should have fewer bugs in it than QW2011 does, despite my experience to the contrary!
MegM0 -
sorry for typos. It's late.MegM said:Dear Lurker,
You are truly marvelous in being willing to come back and try to sort out this chopped up story.
I have used QW2011 for ALL of my quicken work since 2010 and it has never crashed. It has always seemed very stable. in fact, I have used QW2011 or its predecessors almost daily since about 1991. However, the fanciest thing I have ever done with QW is an investment file that contains separate accounts for single mutual funds, so I have not really tested QW2011 on anything as complex as a multi-fund brokerage account. I installed QW2017 on one machine last week, but solely for the purpose of building this brokerage account with newly downloaded transactions through 2018. All of my other QW files remain in Q2011 and I plan to keep them that way (on the theory that "if it ain't broke, don't fix it"). My Quicken files of all vintages are on my own hard drives (just as you suggest), which are fairly new (1 year old and 2 months old) so quite healthy.
I have been making copies of my problem QW2017 brokerage file periodically as I progress through the process of adding missing transactions by hand, but after both first and second crashes, I foolishly continued working on the same file, rather than a slightly older copy of it. (I didn't want to lose the transactions I had just added by hand, but the first crash happened so FAST that I had not yet made a copy of it.) I have now decided, after the latest crash-and-data-failure, to stop -- as you point out, the data loss is very worrisome, and the crashes signify that something is deeply wrong. In fact, I have returned to the QW2011 original (which I did validate before starting this time, just in case). It is hard (tedious, stupid) work but I have not had a glitch since. Best of all, the added months of data all produce holdings reports that match the paper reports. I validated the QW2011 file before starting to add entries (no errors, but "some transactions were changed," which mystifies me!). I should have done that before launching the QW2017 effort laslt week, but I don't think I did (I had no idea my file was afflicted).
I don't think I can figure out the crashes, which do indeed scare me. So I just took the plunge and returned to QW2011 and the hard slogging of making manual entries (and I check them against the paper reports and make a new backup at the end of every month of additions). When I get up to April 2015 (which is the date beyond which my QW2017 files offer downloaded transactions as a tempting labor-saving device), I plan to experiment with a conversion to QW2017 and importing the transactions from the existing file. Or from a newly downloaded file that I can validate first (but this will lack a year of transactions I will still have to add manually.) But I worry that I will be contaminating my clean file (the QW2011 file that I have to convert to QW2017 to do this) when that, which will drive me back to the clean QW2011 file to continue by hand.
Thank you for your fantastic suggestion about downloading .csv files from Yahoo and the like to get full price history and then editing it in Excel to produce a file I could import as new price history.
And it is valuable for me to keep in mine that QW2017 should have fewer bugs in it than QW2011 does, despite my experience to the contrary!
MegM0
