Running, Saving, and Reopening a Parameterized DynamoDB PartiQL SELECT in Tables

Sidharth Bangera — Thu, 08 Oct 2026 18:02:07 +0000

Introduction

When I reuse a database query, I want the query structure to stay consistent while the input value can change.

In this walkthrough, I use Tables by ServerlessCreed, a DynamoDB GUI with a PartiQL Workbench, to run a parameterized DynamoDB PartiQL SELECT, verify the returned items, save the statement, restart the application, reopen the saved query, and verify the result again.

I also include a simple syntax-error recovery check. The test uses a deterministic fixture, so I know the expected result before execution and can verify the workflow against actual data rather than relying only on a success message.

Prerequisites

To reproduce the workflow, you need:

Tables by ServerlessCreed installed. The installer is available from the official download page.
Access to a non-production DynamoDB environment.
A table with predictable test data.
A known expected result that you can compare with the query output.

For this test, I used a table named table_bulk with 120 deterministic items. The fixture was prepared so that 30 items had:

Status = BULK_EDITED

In this table, OrderId is the partition key and Status is the sort key. Because BULK_EDITED appears on multiple items, Status was a useful field for testing a parameterized query that returned more than one record.

1. The query I wanted to reuse

Instead of putting the filter value directly into the SQL, I used a named parameter:

SELECT *
FROM "table_bulk"
WHERE "Status" = {{statusValue}};

The parameter value for this run was:

statusValue = BULK_EDITED

This keeps the query structure reusable while letting the value be supplied separately when the statement is run.

I opened the PartiQL Workbench, selected table_bulk, and entered the statement. Autocomplete suggestions were available again in the v3.3.37 build while I was typing.

After selecting table_bulk, Tables shows the Status attribute in autocomplete while I build the PartiQL SELECT.

2. Supplying the parameter and reviewing the query

When I ran the parameterized statement, Tables opened a Query parameters dialog and detected statusValue.

I entered:

BULK_EDITED

and chose Load for review.

Tables then resolved the parameterized statement to:

SELECT *
FROM "table_bulk"
WHERE "Status" = 'BULK_EDITED';

This review step was useful because I could see the exact statement that would be executed before running it.

After running the parameterized statement, Tables prompts for statusValue; I entered BULK_EDITED and loaded the resolved query for review.

3. Verifying the first result

I then ran the resolved query.

The expected result was 30 matching items because the fixture had been prepared with exactly 30 items whose Status value was BULK_EDITED.

Tables returned 30 items, which matched that expectation.

This was the important verification point for the first run. I was not relying only on a generic success message; I had a known fixture and an expected result before execution.

After running the resolved SELECT, Tables returns the expected 30 items from the deterministic fixture.

4. Saving the statement and reopening it after restart

Next, I saved the parameterized template rather than only the resolved literal query.

The saved statement retained:

SELECT *
FROM "table_bulk"
WHERE "Status" = {{statusValue}};

I then restarted Tables, returned to the PartiQL Workbench, and selected the saved statement from My statements.

The parameterized query itself was still there after restart, but the previous parameter value was not retained. Selecting the saved query opened the Query parameters dialog again, so I entered BULK_EDITED a second time.

That behavior is important: Tables preserved the reusable query template, while the input value had to be supplied again when reopening it.

After loading the value for review and rerunning the query, Tables again returned the expected 30 items.

Check	First run	Reopened run	Expected keys/items	Actual keys/items	Difference
Query template	`{{statusValue}}` present	`{{statusValue}}` present	Same saved statement	Same saved statement reopened	None
Parameter value	Entered `BULK_EDITED`	Re-entered `BULK_EDITED`	Same input value	Same input value	None
Result	30 items	30 items	30 deterministic fixture items matching `Status = BULK_EDITED`	Same 30-item result set observed after restart	None observed

I did not export a separate key manifest for this run, so the comparison was based on the deterministic fixture and the matching 30-item result before and after restart.

After restarting Tables and reopening the saved statement, the parameterized query remains intact and Tables prompts me to enter statusValue again.

5. Recovering from a syntax error

I also tested a simple recovery case by deliberately changing the statement to invalid syntax:

SELECCC *
FROM "table_bulk"
WHERE "Status" = 'BULK_EDITED';

Tables rejected the statement and displayed:

Statement wasn't well formed, can't be processed: Expected data manipulation

The malformed statement remained visible in the editor, so I could correct it directly instead of recreating it from scratch.

After running the deliberately malformed SELECCC statement, Tables reports a syntax error while leaving the statement in the editor for correction.

I corrected the query and ran it again. Tables reported a successful execution and returned 30 items, matching the expected fixture result.

The query history also kept the failed statement and the successful corrected statement as separate entries during this retest.

After correcting the statement, Tables executes the SELECT successfully and returns the expected 30 matching items.

Conclusion

This test confirmed the full workflow I wanted to verify in Tables: creating a parameterized DynamoDB PartiQL query, supplying the parameter value, checking the returned items, saving the query template, reopening it after restart, and running it again with the same expected result.

The saved statement retained the {{statusValue}} placeholder, while the parameter value had to be entered again after reopening. With the same BULK_EDITED input and unchanged fixture, both runs returned the expected 30 items.

The syntax-error check also showed that a malformed statement remained available for correction, and the corrected query returned the expected result afterward.

For this test, the most useful part of the workflow was keeping the query reusable without hard-coding the input value into the saved template, while still verifying the result against a deterministic fixture.

DEV Community: Sidharth Bangera