Looking for best practice for using single-user local database.
Looking for best practice for using single-user local database.
I'm developing an application that interacts with a local database on the users machine using XE4 and ElevateDB. My initial thought was to put the database in a separate folder called Data. This becomes a real pain in the ass because of the Debug and Release locations for both 32Bit and 64Bit.
I understand I can use a Pre-Build command to ensure the folder and data exists in the Debug and Release locations. I'm just wondering if using a folder called "Data" that resides in the same location as the executable is the best location.
Am I overthinking this? Is this just the cost of creating an application that uses a single-user local database?
I'm developing an application that interacts with a local database on the users machine using XE4 and ElevateDB. My initial thought was to put the database in a separate folder called Data. This becomes a real pain in the ass because of the Debug and Release locations for both 32Bit and 64Bit.
I understand I can use a Pre-Build command to ensure the folder and data exists in the Debug and Release locations. I'm just wondering if using a folder called "Data" that resides in the same location as the executable is the best location.
Am I overthinking this? Is this just the cost of creating an application that uses a single-user local database?
Why not put the data where the data belongs: an application specific subfolder of CommonAppData? Don't know about XE4 but in XE6 this can be taken from TPath.GetPublicPath.
ReplyDeleteUwe Raabe hear, hear.
ReplyDeleteUwe Raabe because that means the application and its data are in completely different places. This adheres to Windows design guidelines, but might not be the best design in all cases, e.g. for portable apps.
ReplyDeleteI also prefer to put the data (and configuration files) on the application folder - the problem is that (since Vista) for most users, it means installing outside of "program files" path so the program has access to write on it's own folder (eg. C:\MyProgram). I don't have to track several folders addresses but, for some big companies with very restricted user freedom, it can be a problem.
ReplyDeleteIf the OP is worried about file locations and 32 vs 64 bit, it doesn't sound like he's making a portable app. Otherwise the application code could ensure the existence of a data location using paths relative to the application location, but he still has to do that even when it's located properly.
ReplyDeleteAlthough Michael only mentions the different pathes from the build configurations, a severe problem can exist when a 32-bit and a 64-bit application is installed on the same machine. Assuming you follow the Windows guidelines you would end up with two different database locations when stored in a subfolder of the application.
ReplyDeleteAnd regarding following the Windows guidelines - I am probably not alone when I say that I learned it the hard way: Do not fight the machine!
Not sure this is even a "good" practice, but my data location choice is driven by how I assure that my data will be backed up. I always create a new "Data" folder for use during development under the application folder. After the release version of the program is done, if the program is for my own personal use, I place the data in a separate folder on my D:\ drive. (I put all my data for all my programs on a separate drive or partition to simplify backup, because I always backup my entire D:\ drive.) If the program is for someone else, with their prior agreement before development, I create a separate folder under the "My Documents" folder. Again, this is to help assure backup of data. Nearly all cloud backup programs automatically include the My Documents folder. I use an ini file to store the location of the data folder. (I wrote an ini component that determines whether the program is running under the debugger. If the debugger is running, the ini file is stored with the exe. Otherwise, the component stores the ini file in the proper Windows location under the User's AppData|Roaming folder.)
ReplyDeleteI use ElevateDB and agree with Uwe Raabe and use the commonappdata.
ReplyDeleteThank you all for your valuable comments.
ReplyDelete