Two pieces of AppleScript: one works, one fails—why?

	if foundRecord ≠ {} then
		set theUUID to uuid of item 1 of foundRecord
		return theUUID
	end if

This error traps it for no results.

But why does it not find a record that clearly exists?


Well… from the posts on this thread, it’s not clear it does exist. :wink:

From my database 11…


I can see the damn thing! :sob:

It’s OK - leave it with me: I’ll get there somehow.


Post a screencap of the file you’re seeing in the item list.

Or better, the Info pane’s top sections including Location.

And I was searching for 31/05/2021.

The thing that totally baffles me is that if I leave the answer as the default it comes up with the correct UUID (including if I input that date manually) but if I input any other date it fails.


Edit: to remove more than one me: no wonder, in the circumstances!

Have you tried 5.31.2021?

Yes - and again just now: same error. Please don’t spend too much of your time now on this, I’m getting quite embarrassed about the whole thing! If you have any more ideas, at leisure, just return to the thread when you have time.


No need to be embarrassed.
We’ve all had our :thinking::face_with_symbols_over_mouth: moments in automation.
I’m sure we’re just missing some little detail.

In the replies, is the expected filename, i.e. with the expected date, reported?

1 Like

Thanks for the good cheer! Am sure it’s something quite stupid but have been hammering away at the wretched thing for 24+ hours without getting anywhere!

Let’s relax and come back to it some time. Thanks so much for the support, as usual.


You’re welcome :slight_smile:

tell application "Script Editor"
	display dialog "Enter the link date as DD/MM/YYYY" default answer "01/07/2021"
		--> {button returned:"OK", text returned:"31/05/2021"}
end tell
tell application "DEVONthink 3"
	open database "/Users/stapp/Documents/DevonThink/Diaries.dtBase2"
		--> database id 3
	search "name:Monday 31 May"
		--> {}
error "Can’t get item 1 of {}." number -1728 from item 1 of {}


You’re right. That’s even weirder. The date itself is
current date given «class Krtn»:{weekday:"wday"} --> date "Freitag, 23. Juli 2021 um 19:14:26"
According to script editor.
I give up.

Don’t despair. A date object is displayed using the system’s locale settings. The constants are not coming from that displayed text. They are separate properties of the date object. The display is not the object (“Ceci n’est pas une pipe)”

And there is a way to get a date object to display in a language that’s not the system’s.

Now my brain hurts (and the listing you linked to messes up UTF-8 characters :wink: But I see that you had your hands in this AppleScript solution, too – better to think twice next time I comment a post of yours :wink:

Here’s what I’d do in JavaScript

 const locale = "de-AT";
 const weekdayFmt = new Intl.DateTimeFormat(locale, {weekday: "long"});
 const monthFmt = new Intl.DateTimeFormat(locale, {month: "long"});
 const today = new Date();
 today.setMonth(0); /* change month to January to get a more interesting output */
 const weekday = weekdayFmt.format(today);
 const month = monthFmt.format(today);
 console.log(`It's a ${weekday} in ${month}`);

which tells me It's a Samstag in Jänner, which is a really nice touch for our Austrian friends. I find this approach a tad more convenient and robust than fiddling around with locale files that might be stored in another location in a new version of macOS (and/or change the order of lines or whatever).

But I agree, it is feasible. And date/time are a never-ending source of joy and fun:


I have the impression that @Stephen_C and @BLUEFROG are using different ways to search for the record: @Stephen_C does something with (contents of …) whereas @BLUEFROG uses search. Could that make a difference?

Just a wild guess: one of those literal spaces may not be only a space. Replace them with constant ‘space’ [heh]:

set theTarget to wDay & space & dateDay & space & dateMonth & space & dateYear & ".md" as text

Sorry, catching up with everything…

Not now - see this earlier post in the thread.

The reason I think that’s not the problem is this: why the devil does it work if I delete the default date in the input dialog and then input that default date manually, but then if I input any other date in place of the default it fails? Clearly the default date must be being processed by the code in exactly the same manner as any alternative date, surely? So why does one work and the other fail?

Am slightly battered now but tomorrow if I get the chance I’ll try with many alternative dates (I have thousands of records - covering every day of the past 40+ years - with which to experiment!) to see if any of them work (although I’m not optimistic). Something completely bizarre is going on and I simply don’t for the moment know what it is. I don’t think I’m being completely stupid but am beginning to wonder!


You didn’t identify what’s not working
For myself (Canadian)
Script 1 generated targetRecord Thursday 1 July
Script 2 generated targetRecord Thursday 7 January

Stephen, are you running the script from Script Editor or from within DT (as an embedded script in a rule)? If from Script Editor, could you please post a replies window as Jim did in this response?