The same happens with selected records in the place of selection, btw, with JXA as well. On the other side, retrieving the class of the record returns record, as it should.
I’m wondering if that might be related to the fact that the type of property is also record, albeit a different one, namely the AppleScript datatype.
I possibly have another issue introduced around 3.8.4 that is also present in 3.8.5 running macOS Monterey 12.5.
Once of my rules in Hazel executes a shell script through which DEVONthink is automated using osascript. In below a snippet from the script:
Command='
tell application id "DNtp"\n
launch\n
set theDatabase to open database "'$DevonthinkFolder'/'$DatabaseName'.dtBase2"\n
set theGroup to create location "'$FolderName'/" in theDatabase\n
set theRecord to import "'$FullPath'" to theGroup\n
set the name of theRecord to "'$NewName'"\n
end tell\n
'
This has worked flawlessly for years and imports a file to a given database and location. Which database and location are to be used, is determined elsewhere in the script.
The issue that currently manifests itself is that when the script is executed, DEVONthink first gives a message indicating that the database is already in use and I can continue or abort.
Afterwards, it imports the file, but often not in the correct database that was determined by the script.
I’m confident that the databases in question are not in use elsewhere and that they were previously correctly closed.
Reverting back to 3.8.3 causes the script to run stable again.
Do you have any idea what can cause this and are there things I can do to help figure it out?
Was DEVONthink properly terminated the last time? The most likely reasons for such a message are a crash, force quit, kernel panics or multiple instances of DEVONthink installed (so that the script launches another one which can’t open the database anymore).
BTW:
The current version is 3.8.5 which fixes the original issue of this thread.
This has been working flawlessly until recently, so I’m unsure what has changed.
#!/bin/sh
# This script moves files of to DEVONthink folders automatically
# Variables
FullPath=`echo "$(cd "$(dirname "$1")"; pwd)/$(basename "$1")"`
LoggingFolder="/Users/galsom/Scans/Prepare"
DevonthinkFolder="/Users/galsom/Library/Application Support/DEVONthink 3"
DatabaseName="Inbox"
FolderName="Incoming Documents"
# Write logging information to the log file
echo `date` >> $LoggingFolder/move_to_devonthink_log.txt
echo "Moving [$1] to DEVONthink" >> $LoggingFolder/move_to_devonthink_log.txt
Command='
tell application id "com.devon-technologies.think3"\n
launch\n
set theDatabase to open database "'$DevonthinkFolder'/'$DatabaseName'.dtBase2"\n
set theGroup to create location "'$FolderName'/" in theDatabase\n
set theRecord to import "'$FullPath'" to theGroup\n
end tell\n
'
echo $Command | osascript
mv "$FullPath" /Users/galsom/.Trash/
exit
I recently switched to a new MacBook Pro, and am running 3.8.6. The message of the database already being in use has not yet appeared.
The files are however still sometimes placed in the correct database and sometimes in another on. Running only the AppleScript in Script Editor part also gives the same result.
I have created a screen capture showing the issue. Can I share this through support by email or another means??
The path is the one of the global inbox which is always available and can’t be opened, therefore the result of the command is a missing value and the create location command uses simply the current database.
Thank you for the feedback. The reason for the shell script is that is was an extension of somebody else’s work adapted to my needs, without completely rewriting it in e.a. ApplseScript.
Thanks a lot @cgrunenberg! You feedback helped me to hopefully solve it.
The issue probably was indeed that DevonthinkFolder variable contained an incorrect path.
One thing I noticed is that when the path is correct, but contains an incorrect casing, then the Database '<name>.dtBase2' seems to be already in use! error gets thrown.
E.g. /Users/galsom/Documents/Devonthink/email.dtBase2" contains email.dtBase2 as the database, but the correct spelling is Email.dtBase2. This causes that error to be thrown.
I did previously roll back to 3.8.3 where this was not an issue, so I’m not sure if something changes.