Fix data in bulk, tried on a test copy first
A bulk data mistake is fixed in one pass, tried on a test copy before the live shop.
What it replaces: 2-4 h of preparing, testing and running a database fix
What you write to Claude
„on staging: count products with weight 0 that have a weight in the supplier reference table, show 10 examples, then prepare the update. after I check staging, run the same on production”
The problem
An import set the weight of 1,200 products to 0, so shipping costs are wrong. The back office can't fix this in bulk.
What Claude does
- Claude counts and shows the affected products.
- It shows the planned change and how many products it touches.
- It keeps the old values so the change can be undone.
- It runs on the test copy first, then on the live shop after a new approval.
What you get
Product weights are corrected in one pass, tested before production.
You stay in control
You see every change before it is saved and nothing happens without your yes. This deep repair access uses the separate, extra-protected connection, works only for the few hours you switch it on, and keeps a copy of every changed file or record.
Related use cases
- Try risky changes on a test copy of the shop first
- Report products that haven't sold in 12 months
- Fix a bad import across hundreds of products, with a copy of every change
For developers
- Area
- 5 · Service mode
- Connector
- service connector
- In the free Audit
- no, paid version only
- For
- Developer, Agency / freelancer
- Tools
- ps_db_query, ps_db_execute, ps_revert_change, ps_clear_cache
Step by step
- Counts and samples the affected rows with ps_db_query (service mode on the staging connector).
- Prepares an UPDATE of the product table only, without JOIN, so the row backup applies (values taken from the supplier table, e.g. via a subquery in SET), and shows ps_db_execute's preview: row count and sample.
- Runs in a transaction with max_rows (up to 1000 per call, so 1,200 products go in two batches by ID range); the old values of each row are kept for ps_revert_change.
- You check staging; then the same on production with a new preview and approval.
- A direct database change skips module hooks and caches, so Claude suggests clearing the cache and re-checking shipping costs in the cart.
Safety
Service mode (block 5) works only through the service connector (separate token, allowlisted IP addresses) and only while its time-limited switch is on (1, 4, 8 or 24 h); then it switches itself off, and the owner gets an e-mail when it is switched on. ps_db_execute runs one INSERT/UPDATE/DELETE/REPLACE in a transaction; the preview shows the row count and a sample, and the change is rolled back if more rows than max_rows (up to 1000) would change. A single-table UPDATE or DELETE without JOIN keeps a copy of every changed row, so ps_revert_change can undo it. UPDATE/DELETE without WHERE needs all_rows=true; ALTER/CREATE/DROP/TRUNCATE need allow_ddl=true and cannot be undone. A direct database change skips module hooks and caches, so a block 1-4 tool is used instead whenever one exists.
Last updated: 2026-10-05