Did you relaunch Script Debugger after doing that and installing the lib?
Of course, several times.
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.
No – at least not here when I try it.
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.
OK. Did that. Deleted your script lib, and then pasted it in again. Same error.
I don’t see how Dropbox is involved. All it does is copy changed files to the cloud.
It’s not a symlink issue. I removed the symlink, and copied your lib into the actual Script Libraries folder. Restarted SD6, got same error.
FWIW, I was able to successfully do this:
version of sqlLib -->1.0.0
OK, I’m emailing you a new copy to see if there’s a corruption problem.
Must have been. Issue is partially resolved:
- 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
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).
is there a reason the Library is locked? I was finding it useful to look at the handlers.
Plus, without a dictionary it’s kind of difficult to know what all the possible and working commands are.
(I’m thinking I may need to find an SQL cheat sheet for queries. Would that even help?)
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.
Yes, https://sqlite.org is your friend, along with a search engine.
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”:
###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:
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.
And why is it the real folder and not a symlink? It’s because Dropbox has issues if you instead put the symlink in its folder.
So it’s not unexpected that there might be issues when you put other symlinks in a Dropbox folder.
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.
This is a simlink inside of Dropbox:
that points to this folder: