Quicken database on a NAS - still not recommended?
I have had a Raid level 1 NAS on my home network for a number of years. I decided to relocate my Quicken database to the NAS so I could access it on multiple computers. I moved my quicken database files to it and attempted to have quicken open the files on the NAS. I got a message window that said something to the effect: you are attempting to open a file on Dropbox, cloud server, or some remote device. This is not recommended…..
Seriously?? in 2025 this is still not recommended (supported? trustworthy?)
Reliable methods to access, use, and safeguard remote file usage has been around since the 1970….
I'd like to hear from community members who use (attempted to use?) a remote data file with Quicken if they found issues in doing this. I am wondering if I should attempt to use it this way.(with the appropriate backups performed before/after on both local and remote drives)
Answers
-
Unlike data files used with many other applications, Quicken's data file is a database, and database files are not written to disk in the same way as text documents or photos or spreadsheets. As a result, database files written for a single computer often run into problems when stored on cloud storage services which store/update blocks of data differently than a local hard drive. There are, of course, databases built to be used in a client-server environment for remote use or multi-user use — but the SQLite database used by Quicken is not built for those environments.
There are many problem reports of various types of incorrect behavior which get posted on this site, which turn out to be due to storing the data file on a cloud storage service. Sometimes, problems pop up after users say they have been using cloud storage for a long time. I don't think there's a way to say definitively what will or won't work, or whether you will run into problems; all we can say is that there is a risk, which is why it's not a supported configuration by Quicken.
You might consider tweaking your workflow to use your NAS safely: storing a compressed Quicken data file (backup or .zip) on your NAS, and copying it to and from your desktop, where you expand it when you're using Quicken. For example: place your Quicken data file on your desktop, launch it, use it. When you quit, Control-click on the data file and select Compress, which will create a .zip file. Move that .zip file to your NAS, and delete the local data file. Next time you want to use Quicken, copy the .zip file from your NAS to the Desktop, and double-click to expand it. Yes, this requires the extra steps of compressing and moving the file when you're done, and moving and decompressing the file when you want to use it, but those steps take only a couple seconds. (You can save one step by designating a location on your NAS as the default location for your Quicken backup files, so that when you quit Quicken, a backup is created there without you needing to compress and move the file there. I don't recommend this method because I believe there's a potential for an issue with Quicken Cloud over time if you're starting from a backup file every day, but I might be wrong.)
Quicken Mac Subscription • Quicken user since 19930 -
And if you store the working data file in a shared location, there is always a risk that 2 computers will try to access it at the same time. That will definitely cause problems.
QWin Premier subscription0 -
See this FAQ on how to have your data file on a NAS and automatically copy it to your local harddrive, use Quicken and then copy it back to the NAS. It protects against the two computers trying to grab the file at the same time also.
-splasher using Q continuously since 1996
- Subscription Quicken - Win11 and QW2013 - Win11
-Questions? Check out the Quicken Windows FAQ list0 -
Thank you for the insight/comments/suggestions. (Way) Back in the day, I developed user interface applications that talked to data bases on local networks. There are many ways to make transactions appear to be atomic. The use of locks and semaphores will prevent potential interleaving of data from two notes. Worst case is the file is locked the entire time the user accesses it, preventing anyone else from using it. Various webserver architectures have long been updating databases via back office methods. As the article points out, the entire architecture of quicken was done without the concept of remote databases. I suspect that re-architecting and revamping the code would cost more than Quicken wants to spend, so A warning to the user…beware.
I'll just write some scripts to move data files around reliably when I want to use quicken on another machine. Again, thanks for your insight…..
0 -
Seriously?? in 2025 this is still not recommended (supported? trustworthy?)
This statement makes an assumption just isn't true.
That time has anything to do with it.
Quicken Inc isn't going to change the whole architecture of Quicken just because another year has passed.
What's more even developers don't seem to understand the situation and the complexity of what is involved.
First off, let's talk databases. Most applications that use databases, use server-based databases, and as such the complexity of the synchronizing of transactions and backup processes is hidden from the user. These server-based databases have special hooks and procedures to make sure that they can be backed up properly. What's more for Quicken Windows, its database isn't as robust for fixing problems like a power loss at the wrong time as the modern ones are. But even at the time Quicken's database was designed, Quicken's database was "less featured" in this regard than any server-based database at the time, for the very reason that it was a stand-alone database.
Here is the truth not only about Quicken's database, but pretty much all programs, almost none of them have code in them to recover from any kind of file write/read problem. They almost all assume 100% reliable "disk". For the people that can ensure that their network performs at that same level they can get away with Quicken's data file on a network drive for instance. And let's talk about what is the real problem with using Dropbox or OneDrive, … It is actually the very mechanism that is used for preventing "two users at the same time". In a server-based database they get "requests" and as such can control this, since the design is for multiple users. For Quicken Windows data file it is single user, and the "blocking" is simply the file lock on the QDF file. The problems arise when either one of these "Cloud folder" services ignores that lock, or for the fact that Quicken expects to get access to that QDF file whenever it wants. As in, at times it closes the data file (like to run Validate, or to do a backup) and it expects to be able to turn around and open that data file again. If the Cloud folder service comes in and locks the data file to do the upload, that blocks Quicken and Quicken will most likely report this as not "not able to access" data file error.
Now talking about real network drives. The first thing to understand is that saying "Network drive" tells you very little. There are tons of network protocols. The network drive for instance might be on another Windows machine or a NAS (which is most likely going to be running Linux). And I can tell you that locks across network drives have always had problems. Not to mention that people might the connected wirelessly, and maybe one person's network is rock solid and another is flaky. Quicken Inc certainly doesn't want to try to support such a thing.
Move to more modern times and you get Quicken Mac's stand-alone database, and it has the better recovery features, so what's the problem with being stored in places like iCloud?
Well, I would have to say it is because it "isn't 'a database'" (BTW neither is the Quicken data file).
If all the data was store in the database, then there would probably be no real problem for the Quicken Mac data file to be stored on say iCloud, but it isn't. Both Quicken Windows and Quicken Mac are in fact a database with extra files stored in a compressed file system. And those other files can get out of sync/damaged and such, not to mention on Quicken Mac there are permission problems that come up.
Signature:
This is my website: http://www.quicknperlwiz.com/0 -
Thank you for your replies. I respectfully disagree with some of the points but arguing over them will not change reality. One important point is the assumption about time. Twenty-five + years is a long time to ride an architecture (product) without plans to update it to work in a net centric environment. While I admit that the whole cloud-based accomodation can be a challenge, approaches have long been developed to handle files on NAS and LANs. I've done it, both HW and SW solutions.
Now that I know the constraints of the past will continue into the future, I'll need to work around them the best I can. On the plus side, Quicken (seemingly) had become a bit more solid-at least for basic operations.0 -
@three_jeeps There is one more constraint that I didn't mention that overrides all other concerns. Quicken Inc is a small company, in total only about 200 people. And they are developing/maintaining Quicken Windows, Quicken Mac, the Mobile/Web, and Simplify and now even a business version of Simplify. They simply do not have the resources for a full rewrite which would be needed to properly handle this.
And in fact, I think Simplify and now the business version of it, tells you what Quicken Inc's approach is for solving these problems. Quicken is the past and they will keep it going for as long as they can, but I think they feel that the online development is the way to go. The newer generations accept this model, and it is whole lot easier to deal with for the company.
Signature:
This is my website: http://www.quicknperlwiz.com/0 -
@jacobs wrote:
the SQLite database used by Quicken is not built for those environments.
In all the years I've been reading forum posts, I've never seen this claim before (that SQLite is being used). Is that really true?
0 -
@jtemplin SQLite usage is I think pretty common for Mac apps since support for it is built into Mac OS as part of the Core Data system it provides. I don't know if Quicken Windows makes use of SQLite, but can confirm Mac data files contain a SQLite database.
0 -
Quicken for Windows uses a proprietary database format for its data files. Unlike Quicken for Mac, which uses SQLite, the Windows version relies on its own database technology to manage and store financial data. This proprietary format is designed to ensure data integrity and support the various features and functionalities of Quicken for Windows.
0 -
The database in Quicken Windows pre-dates SQLite by a LONG time. At one time it was speculated that it was a standalone database from Oracle, but I have never seen anything confirmed by Intuit or Quicken Inc on that score.
Signature:
This is my website: http://www.quicknperlwiz.com/0 -
Quicken for Windows uses a proprietary database format for its data files. Unlike Quicken for Mac, which uses SQLite, the Windows version relies on its own database technology to manage and store financial data. This proprietary format is designed to ensure data integrity and support the various features and functionalities of Quicken for Windows.
What struck me ironic is the statement that Quicken Window's database is "designed to ensure data integrity", yet it is in fact less robust than the SQL database used by Quicken Mac. Quicken Windows has database repair routines like Validate and Super Validate; you don't find those in Quicken Mac because the SQL database isn't susceptible to the types of database corruption that can occur in older databases.
(I'm not making a big deal about this; it just seemed funny to me. We all understand that the Quicken Windows database is much older than modern SQL databases, and that Quicken's code is highly integrated with the database, so it can't easily be changed.)
Quicken Mac Subscription • Quicken user since 19930 -
You might be surprised, (along with a lot of Windows SuperUsers and others) that I don't really believe that Validate and SuperValidate find "database corruption" very often.
I think most of the time what it really finds are "software bugs".
What I don't think many people realize is that Validate and SuperValidate do much more than "check the database", and even in the checking of the database some of what it finds is more about "oops that shouldn't have happened".
For instance, recently there was a discussion on a warning that Validate gave about the "QEL file". This is actually a separate file that is included in the compressed Quicken data file that tracks the unique Ids of transactions. There is also another separate file "QPH" that tracks the security prices. So, these aren't the "database", but it is Validate that reports problems it might find.
Now on my belief about "database corruption". Let's talk a bit about how these databases are arranged. Typically, you have "lists" that then point to the actual data. Like the Account List, the Category List, … There is going to be a lot of these kinds of relationships. Now the thing to understand is it is very possible for the code to have a bug in it and not update either the "pointer to" or "the item a pointer is pointing to".
To me database corruption is something like, the program is in the process of updating the database and the network fails, will the database be left in a state where it has only written part of the data out, and if so, does it have something like journaling to fix such a problem? Basically, for this to be the cause you need a write failure. What was the last time you had a write failure on your machine?
So, Validate has always been stated as a "database check", but in reality, what it is, is a "data consistency check". The data inconsistencies can come from "the database", or some hardware failure, but as a software engineer my bet is on the code for most of the problems.
BTW look at this dialog:
You will notice that there are options for "other things, like the price history, and rebuilding the security investment lot data" not to mention fixing printer settings.
Here is the log of a typical "no error" Validate run:
[Wed Mar 12 22:26:15 2025]
File: "c:\Quicken\Current"
QDF:
Validating your data.
No errors.QEL:
No read errors.QEL:
All internal consistency checks passed.[Wed Mar 12 22:27:18 2025]
Maximum security reference: 229, number of securities: 228.
Analyzing securities.
All security references are within the normal range.Validation has completed.
One of the questions that have come up is what the "Max security references" is all about. And the response from Quicken Inc?
They have notice that "for some people/reason" the number of references "blows up" and they wanted to track that to see if they could figure out why. That isn't going to be "database corruption" that is a coding error.
Another thing that the Quicken Window database gets accused of is "slow performance". From what I can tell, it is in fact a pretty good database as far as performance goes. What really sucks is the Investment register GUI, and how it looks like they are recalculating all the security lots in a given register on the fly, instead of having some "caching system". Quicken Windows certainly suffers from "too much updating of data that isn't needed" because the system wasn't setup to "only refresh what was needed" at its core.
The investment register GUI is made up of a whole bunch of widgets, instead of something more dedicated to the purpose. Here is where Quicken Mac's history should ring a bell, and why the Quicken Mac developers push back on things like the Downloaded Transactions tab and the two-line register.
But let's talk "non-investment account". Another discussion was on a person that had three accounts that had about 6,000 transactions in each and had "performance problems". So, I was curious exactly how Quicken Windows really performs with a lot of transactions in a register provided there wasn't "some other kind of problem". Note that "performance problem" was "I'm importing 500 transactions in QIF format, and it is taking an hour." BTW when such problems come up, I suspect "outside forces", like anti-virus software.
So, I started with that, imported 500 transactions, time, about 10 seconds. I then proceeded to ramp up and quickly got to 5000, with the time being in the seconds as I started. Over time the performance did go down. When I got to about 200,000 transactions in that register the importing of the 5000 transactions was taking about 1 1/2 minutes.
And what about entering a transaction into a register with 200,000+ transactions?
Less than a second.
In my normal data file, I have 57,379 transactions, 136 accounts, 388 categories 352 memorized payees.
Time to bring up a report from the earliest date to today, no interval, a couple of seconds. Note with the report you have a graph and a table of the data.
Change interval to by year (since 1996), a maybe 5 seconds at the most.
Let's give it a real challenge. Interval, by day. About 30 seconds. I'm pretty sure the limiting factor here is how fast it can push all that data in GUI. In fact though, Quicken restricts the table to 250 columns.
Signature:
This is my website: http://www.quicknperlwiz.com/0 -
Well all that makes sense. I was hoping that @jacobs meant SQLite on Win Quicken—that would allow a database-savvy person to hack the database to export its data.
When a software company folded and shut down its license servers, many users were stuck without a way to export their data from the program. When I discovered there was an MS Access database under the hood of the backup format, I was able to write code to query and export that data into other usable formats.
0
