Get used to creating a folder named for your app, in the ApplicationData folder (or maybe Documents)
On app startup, check the folder exists
If not, create it
When it exists, check the db exists inside it
If not, create a new one, (or maybe unzip a populated one you include in the app bundle)
That way, your debug app doesnt need to work out where it lives, and isn’t trying to update a db which is local to the app.
(windows doesnt allow that and Mac doesnt like it)
pesudocode
[code]dim f as folderitem
f = specialfolder.applicationdata.child(“myappname”)
if not f.exists then f.createasfolder
f = f.child(“theddb.db”)
if not f.exists then
//create or unzip
end if
+1 …although if you are going to produce code to run on Windows, My Documents can be moved to a non-local server and will not be available if they are disconnected from the network. We used to see this a few times a year with users on Laptop that are on the road and didn’t have access to their network. Use ApplicationData as Jeff said, it will save you headaches down the road.
And pick up TPSF for accessing in-app resources. It uses declares on Mac to be sure you’re doing it right, and handles the different possibilities of folder names on Windows. Plus it offers easy cross platform access to an Application Data folder for your app, so you don’t have to find it yourself.
If you ever have any intention to sell this app on the MAS, you better follow Jeff’s advice and place the database file in your own folder with ApplicationData.
Place the database file in Resources, then copy it to ApplicationData on first run like so (Using Tim Parnell’s TPSF) :
dim f as folderitem
f = specialfolder.applicationdata.child("myappname")
if not f.exists then f.createasfolder
f = f.child("theddb.db")
if not f.exists then
//create or unzip
dim mydatabase as folderItem = TPSF.Resources.child("theddb.db")
mydatabase.Copyfileto(f)
end if
//Use f as before.
What you are doing right now would not pass Apple’s reviewer.
commercial or not, you should still follow advice like Michel provided.
Use of “specialfolder” and “child” will solve 99% of of your issues if used properly.
Although I agree with you, I am not one to tell someone else how to do their job. I’ve been on the other side of the fence where I can’t follow the “recommended” procedure (for one reason or another). Just offering some additional suggestions in case this is one of those cases.
Sorry… I totally disagree… If there is a method that is reccommended, and you don’t (or refuse) to attempt it, then you are saying “Nah, I don’t really want your help, because I want my broken way to work”… and in those situations, I move on, so as to not waste my time. Doing it the “right” way it will work both in the debugger and compiled.
I don’t think Jim is saying anything like that. There are times when just getting an answer quickly to a research problem is a lot more important than doing it “the right way”. The first time I dove into the Application Support folder, it took a bit of experimenting and work to get it working right, maybe Jim doesn’t have the time at the moment. I think it is worth taking the time to see how it works, but my situation is likely different than his.
Jim, running in the debugger is all the more reason to put the database in a fixed location outside the app. It will save you having to copy the file all the time and allow you to save the data from one run of the app to the next.
[quote]This app I’m working on is NOT a commercial product. Will more than likely never “Build” an object, just run as debugger,
Still can’t get it to work.[/quote]
OK.
Put your database in Documents. Easy.
Change your code to this:
dim mDBName as string
dim f as FolderItem
f = Specialfolder.Documents.child("user.db")
dbf = App.ExecutableFile.Parent.Parent.Parent.Parent.Child("Databases").Child("user.db")
However I’m going to put the db in a common location outside of the project folder.
This line of code help me to figure out just what the solution was:
[quote]
s = App.ExecutableFile.Parent.Parent.Parent.Parent.Name[/quote]
