ValidationException: Unexpected from source

TL;DR — Der Tabellenname in deiner PartiQL-FROM-Klausel enthält Zeichen, die der Parser unquotiert nicht akzeptiert — meist einen Bindestrich. Setz den Namen in doppelte Anführungszeichen (SELECT * FROM "my-table"). Einfache Anführungszeichen funktionieren nicht: In PartiQL bedeuten sie ein String-Literal, keinen Bezeichner.

Was es bedeutet

ValidationException: Unexpected from source

Der PartiQL-Parser liest FROM my-table als den Bezeichner my, gefolgt von unerwarteten Tokens — der Bindestrich ist innerhalb eines bloßen Bezeichners nicht gültig. DynamoDB-Tabellennamen dürfen rechtmäßig -, . und _ enthalten, sodass ein völlig gültiger Tabellenname in PartiQL trotzdem nicht parsebar bleiben kann, bis er in Anführungszeichen steht. Dasselbe gilt für Namen, die mit PartiQL-Schlüsselwörtern kollidieren.

Warum es passiert

Der Tabellenname enthält einen Bindestrich oder Punkt — users-prod, app.events. Bloße Bezeichner können sie nicht tragen.
Framework-generierte Tabellennamen — Tooling, das eine Umgebung oder Stage an den Tabellennamen anhängt (z. B. Todo-dev), ist der klassische Weg, wie ein Bindestrich hineingerät, ohne dass du ihn wählst.
Einen Index ohne Anführungszeichen abfragen — die Form "table"."index" braucht doppelte Anführungszeichen um beide Teile.
Einfache statt doppelter Anführungszeichen — FROM 'my-table' scheitert ebenfalls: einfache Anführungszeichen bezeichnen in PartiQL ein String-Literal, keinen Namen.

So behebst du es

Setze den Tabellennamen in doppelte Anführungszeichen:
```
SELECT * FROM "users-prod" WHERE pk = 'USER#42'
```
Setze beide Teile in doppelte Anführungszeichen, wenn du einen Index abfragst:
```
SELECT * FROM "users-prod"."email-index" WHERE email = 'ada@example.com'
```
Behalte einfache Anführungszeichen nur für String-Werte — Namen in doppelten Anführungszeichen, Werte in einfachen. Sie zu verwechseln erzeugt genau diese Klasse von Parse-Fehlern.
Setze in generierten Statements defensiv Anführungszeichen — wenn dein Code Tabellennamen in PartiQL interpoliert, gib sie immer in doppelten Anführungszeichen aus; das ist auch dann gültig, wenn der Name sie streng genommen nicht bräuchte.

DynoTables PartiQL-Editor übernimmt das Setzen von Anführungszeichen bei Bezeichnern für dich — mit Inline-Diagnosen und Quick-Fixes für genau diese Klasse von Parse-Fehlern — und der DynamoDB Expression Builder zeigt die äquivalente native Query/Scan-Anfrage, wenn du das PartiQL-Parsing lieber ganz umgehen möchtest.

In DynoTable ausführen

DynoTable's PartiQL editor double-quotes table and index names automatically — run SELECT * FROM "my-table" with inline diagnostics bevor du paste the statement into SDK code. Öffne die Tabelle mit ⌘K to confirm the exact table name (including dashes) from the sidebar.

When PartiQL parsing keeps failing, switch to the Query Builder for the equivalent native request. Profilwechsel (⌘P) and Verbindung testen on Einstellungen → Profile keep the statement pointed at the right table. Siehe Mit AWS verbinden und Installation.

Quellen

PartiQL select statements for DynamoDB (verifiziert 2026-07-13)
Supported data types and naming rules (verifiziert 2026-07-13)

So reproduzierst du es

Ein PartiQL-Statement, dessen FROM-Quelle kein Tabellenname ist. Der Parser lehnt es ab, bevor er überhaupt nach einer Tabelle sucht, das reproduziert sich also an jedem Endpunkt:

await client.send(new ExecuteStatementCommand({Statement: 'SELECT * FROM 123'}));

Echte Ausgabe:

ValidationException: Unexpected from source
HTTP 400

Contrast it with an unquoted but otherwise valid name: SELECT * FROM repro parses fine and fails later with ResourceNotFoundException wenn no such table exists. Unexpected from source is strictly a parse failure, so read it as a syntax signal, not a missing-table one.

Referenzen

Zuletzt verifiziert am 2026-07-13 gegen die oben verlinkte offizielle AWS-Dokumentation.

Am 2026-07-26 gegen DynamoDB Local 2.x mit dem AWS SDK for JavaScript v3.1095.0 reproduziert — die Ausgabe oben ist wortgetreu.