SQLiteDatabase

Dim Conn As New SQLiteDatabase
Dim f As FolderItem
f = New FolderItem("/Users/alexiscolon/Dropbox/DPF_app/SF_DPF.db") <<<< way this no works
Conn.DatabaseFile = f
If Not Conn.Connect Then
MsgBox Conn.ErrorMessage << error no found
Exit sub
End If

New FolderItem defaults to AbsolutePath. Try

f = New FolderItem("/Users/alexiscolon/Dropbox/DPF_app/SF_DPF.db", FolderItem.PathTypeShell)

A usefull function I found in our community is GetRootFolder, so you can put your database somewhere in a path related to your application:

Dim f As FolderItem = GetRootFolder.Child(“mydatabase.sqlite”) puts your database in the same directory as your application. When debugging you can use another path for your database:


Function GetRootfolder()
Dim RootFolder As FolderItem

If DebugBuild Then
	#if TargetWin32
		RootFolder = App.ExecutableFile.Parent.Parent
	#elseif TargetMacOS
		RootFolder = App.ExecutableFile.Parent
	#endif	
Else
	#If  TargetWin32 Then
	  RootFolder = App.ExecutableFile.Parent
	#ElseIf TargetMacOS Then
	  RootFolder = App.ExecutableFile.Parent
	#EndIf
End If

Return RootFolder


Thats really not a useful function for Windows for deciding where to put an updateable document.
If you create a document in the application folder, normal permissions in Windows will not allow you to update it.

On Mac and Windows, anything you need to update should go in the Application Support folder (in a folder named for your app) , or maybe if it is user amendable stuff, into the Documents folder (because the Application Support folders are usually hard for the end user to browse into)

Thanks

Amazed nobody mentioned this… but NEW is not required with a Folderitem

dim f as FolderItem
f=SpecialFolder.UserHome.child(“dropbox”).child(“DPB_app”).child(“SF_DPF.db”)

of course proper checks for nil and exists should be included here as well

I saw that earlier today and was going to say something but got distracted by other…squirrel!

That should be a compiler error like trying to do new Recordset.

It is if you’re using the constructor that takes a string. Granted, most of the time, people use a function that returns a folderitem, so in code like

dim f as new FolderItem
f = GetFolderItem("foo")

You create a folderitem object and immediately discard it, so yes, using NEW here is superfluous. However, I don’t see how that is germane to this discussion.

no but what is germane is the proper way to create the path… using CHILD as illustrated.

But you CAN use NEW with folder item & specify a path just like in GetFolderItem

Dim f As FolderItem f = New FolderItem("/Users/alexiscolon/Dropbox/DPF_app/SF_DPF.db", FolderItem.PathTypeShell)

is perfectly legal as is

dim f as FolderItem f=SpecialFolder.UserHome.child("dropbox").child("DPB_app").child("SF_DPF.db")

Theres maybe some fringe cases where they might not be the same item but I doubt that

Detecting the use of new when unnecessary then becomes tricky since you could do

Dim f As FolderItem
f = New FolderItem("/Users/alexiscolon/Dropbox/DPF_app/SF_DPF.db", FolderItem.PathTypeShell)
// more code in-between here
f=SpecialFolder.UserHome.child("dropbox").child("DPB_app").child("SF_DPF.db")

and now is the use of new incorrect at all ?
You have to start doing code flow analysis to be sure.

You could argue that New Folderitem with no arguments is invalid.

I suppose you could
Not sure its much worse than GetFolderItem("") though since they both end up being references to the same disk location

And I doubt the code flow analysis is on the list of TO DO’s at the moment :stuck_out_tongue:

Didn’t know that. In that case, new folderitem is perfectly legit. It’s not like new recordset at all.

recordset has ONLY one real true way to get one that works - so its quite simple to diagnose

folderitem not quite so easy