So that didn’t work out too well. The main problem is there’s no way to coerce query results to lists/records without using ASObjC in the calling script, which is otherwise unnecessary. Getting around that means a couple of important changes.
I just tried the same thing on a different Mac. It gave me the same error.
Any issue with the script lib and framework being in a folder with a symlink?
Other libs work fine here.
But that screenshot looks odd – FMDBAS.framework is < 400 KB here. The lib package is only 395 KB.
Frameworks use symlinks internally, so it could be something has become confused. Try installing again, and make sure you do a delete-and-copy rather than a copy-by-replace.
If that doesn’t fix it, it’s possible Dropbox isn’t happy with nested symlinks.
Runs fine with your lib in the normal Script Libraries folder
But gets same error if your lib is in a symlinked folder.
Since all of the other libs I use work fine in the symlinked folder, it must be the framework that’s causing the issue. Can I get a version with the lib and framework as separate files?
There’s not much can be done about that – symlinked Script Library folders are officially unsupported. I suspect the problem is nesting of symlinks (frameworks always include their own symlinks).
It’s probably also worth logging a bug/feature request with Apple.
You can separate them yourself easily enough. Control-click on the lib, and the framework is in /Contents/Frameworks/. Just drag it from there to ~/Library/Frameworks.
This is the nub of the problem, and I’m just not seeing that here.
If I understand correctly, you are putting your Script Libraries folder in the Dropbox folder, and the symlink in ~/Libraries. And from what I’ve read, it has to be done this way around – if you put the symlink in the dropbox folder, Dropbox doesn’t know when things change, and doesn’t propagate any changes.
That suggests that symlinks pose a challenge to Dropbox – and frameworks are built around symlinks.
Your earlier screenshot also shows a framework size bigger than any I’ve released, so something has gone astray at some stage. And it’s only you and Dropbox that read and write into that folder, AFAIK.
So I can’t actually point my finger at Dropbox for this – but I can’t see anything else to suggest (unless it’s a 10.11 thing).
It’s partly a support thing, really. If it’s editable and someone says they’re having a problem, I can’t be sure what code they’re actually running. I’ve had this sort of problem before…
That said, there’s no reason to hide the code – I can include a copy of it. It probably won’t enlighten you much about what’s happening, though, because that nearly all happens in the framework. (FMDB is open source, so you can read that code too. FMDBAS mostly just wraps that code in a more AS friendly way.)
Here it the lib code with lots of stuff snipped for brevity:
use AppleScript version "2.4" -- Yosemite (10.10) or later
use framework "Foundation"
use framework "FMDBAS"
script forInheritance
--
end script
on scriptObjectDbInit()
script
property parent : forInheritance
property theRealSQLDb : missing value
on underlyingFMDatabase()
return theRealSQLDb
end underlyingFMDatabase
on openReadOnly()
theRealSQLDb's openWithFlagsAS:1
end openReadOnly
on openReadWrite()
theRealSQLDb's openWithFlagsAS:2
end openReadWrite
on openReadWriteCreate()
theRealSQLDb's openWithFlagsAS:6
end openReadWriteCreate
on |close|()
theRealSQLDb's closeAS()
set my theRealSQLDb to missing value -- so script doesn't need to store pointer
end |close|
on writeOpenInMemoryDbToFile:fileOrPath
theRealSQLDb's writeOpenInMemoryDatabaseToFileOrPathAS:fileOrPath
end writeOpenInMemoryDbToFile:
on beginTransaction()
theRealSQLDb's beginTransactionAS()
end beginTransaction
on commit()
theRealSQLDb's commitAS()
end commit
on rollback()
theRealSQLDb's rollbackAS()
end rollback
-- lots more similar handlers snipped
end script
end scriptObjectDbInit
on makeNewDbWith:fileOrPath
set myRealSQLDb to my scriptObjectDbInit()
set thisSQLDb to current application's FMDatabase's databaseWithFileOrPathAS:fileOrPath
set myRealSQLDb's theRealSQLDb to thisSQLDb
return myRealSQLDb
end makeNewDbWith:
on makeNewDbInMemoryAndOpenedFrom:pathOrFile
set myRealSQLDb to my scriptObjectDbInit()
set thisSQLDb to current application's FMDatabase's databaseInMemoryAndOpenedFromFileOrPathAS:pathOrFile
set myRealSQLDb's theRealSQLDb to thisSQLDb
return myRealSQLDb
end makeNewDbInMemoryAndOpenedFrom:
They’re all pretty much covered in the new Read Me file.
Shane, you could be on to something. This is very strange.
On a hunch, I copied your last zip file (SQLite Lib.scptd.zip) with just the SQLite Lib file to one of my local folders, not under the DropBox setup. I unzipped the file, and then copied the Lib file to my symlinked Script Libraries folder under the DropBox setup.
Now when I run your latest script (as above), it works fine.
So, it would seem that unzipping a file that is stored under the DropBox setup caused some problem. This is very strange, because I have unzipped many other apps under DropBox, and I’ve never had this issue. But maybe that’s because all of those apps ended up in my normal Applications folder, which is, of course, NOT symlinked.
Is there some way I can do a file compare on the two SQLite Lib.scptd files, so I can identify what changed when I unzipped it in DropBox?
If I can determine what changed, then I can file a Bug Report with DropBox.
I’m not sure a file compare is going to help much.
But the fact that you have to link the Script Libraries folder as you do in the first place suggests to me it’s unlikely Dropbox can do anything about the issue.
If I had to guess, I’d do a bit of hand waving and say that Dropbox is getting confused trying to sync both the symlinks and the folders they’re pointing to and getting them out of sync somehow.
I don’t know what you mean by “you have to link the Script Libraries folder as you do in the first place”. I’m using a symlink in the normal, typical manner.
Just to be clear, here’s my setup:
In my ~/Library folder, I have a symlink named “Script Libraries”:
The symlink points to a normal folder in my DropBox Setup, named “Script Libraries”:
/Users/Shared/Dropbox/SW/DEV/LINKED_FOLDERS/Script Libraries
###The “Script Libraries” Symlink
IAC, I’ve done enough tests now to convince myself that the issue is caused by a framework being in the script lib package, when the package is in a folder synced by Dropbox.
This fails consistently: using the SQLite Lib.scptd when that package is in a folder synced by Dropbox
Each of These Work consistently:
Pause the DropBox sync service, and use SQLite Lib.scptd in the symlinked folder.
Put the SQLite Lib.scptd in the normal non-symlinked, ~/Library/Script Libraries folder
Remove the FMDBAS.framework package from SQLite Lib.scptd, and put it in ~/Library/Frameworks, but keep SQLite Lib.scptd in the symlinked Dropbox folder
I don’t understand this. The ONLY folder DropBox is syncing is the “Script Libraries” folder here:
/Users/Shared/Dropbox/SW/DEV/LINKED_FOLDERS/Script Libraries
It is NOT syncing the symlink to this folder.
This is the ONLY issue I have had with DropBox over the many years I’ve been using it. I have a whole set of folders in the DropBox sync path that I have either symlinks or aliases (all outside of the sync path) that point to these folders. Until now, this has allowed me to keep all of my Macs in sync with virtually no effort or issues.
Thanks for your help in trying to resolve this issue.
I mean that Dropbox must have the “real” folder rather than the symlink – you can’t do it the other way around and put a symlink to your Script Libraries folder in the Dropbox folder. If symlinks caused no issues for Dropbox, you would expect it to work fine either way. But it doesn’t.
Within a framework folder there are both folders and symlinks to those same folders – both are in the sync path, and I’m speculating that that is confusing Dropbox.
As I explained above, the Script Libraries folder in the DropBox path is a real folder, it is NOT a symlink. So Dropbox should not have any issues with it.
I must be missing your point, and perhaps you’re missing minel
It is a real Mac folder. It is not a symlink. DropBox knows nothing about another file, outside of the DropBox setup, that is a symlink that points to this folder.
That does not appear to be the case, based on a test I just ran.
I put a symlink in a folder inside of the DropBox setup that points to a folder outside of DropBox. When I double-click on the symlink, it opens the target folder just fine.
