Database & Performance for PowerBuilder Applications
Oracle, SQL Server and PostgreSQL work under live PowerBuilder applications. PL/SQL and T-SQL refactor, index strategy, execution-plan tuning, DataWindow query optimization — done surgically while the system stays in production.
Concrete deliverables in a Database & Performance engagement
Database work under a live PowerBuilder application is high-risk if done loosely. Each item below is a discrete work product with measurable before/after — so it is obvious whether the change helped, hurt or did nothing.
Schema review and dependency mapping
Tables, views, packages, triggers and the PowerBuilder DataWindows that touch them. The map you need before any structural change is considered.
PL/SQL package and procedure audit
Existing Oracle PL/SQL: code review, anti-pattern flags, parameter-vs-substitution analysis, exception handling, bind-variable hygiene. Output: ranked refactor list.
T-SQL stored procedure and view audit
Same for SQL Server: stored procedures, views, triggers, cursors-vs-set-operations, parameter sniffing exposure. Ranked refactor list and quick wins separated from structural changes.
Index strategy and execution-plan analysis
Which indexes are missing, which are unused, which are blocking inserts. Execution-plan analysis on the actual hot queries — not theoretical ones.
Long-transaction and blocking audit
Locking patterns, deadlock hotspots, transactions that should have committed earlier. Common cause of mysterious slowness, often invisible until measured.
DataWindow query optimization
Optimizing the SQL generated by PowerBuilder DataWindows without touching the UI: retrieval-arguments, filter pushdown, paging strategy, server-side cursors where they belong.
Connection pooling and timeout review
How the application opens connections, how it holds them, what happens during network blips. Often a single configuration change pays for the whole engagement.
Database migration plan
Oracle 11g → 19c → 23ai. SQL Server 2014 → 2022. MSSQL → PostgreSQL evaluation. Concrete plan with PB compatibility audit before any migration starts.
Typical situations behind a Database & Performance call
Database engagements usually surface because of a number on a dashboard — response time, lock count, CPU. The trigger is concrete; the cause rarely is.
Five years ago it was fine. Today users wait. Hardware was upgraded twice and didn't help. The bottleneck is in the SQL — probably not where everyone assumes.
Oracle 11g (or 12c, or 19c) is approaching end of support. The DBA team is ready. The PowerBuilder application is the only blocker — compatibility unknown, character-sets uncertain.
Random transaction failures, retries that don't help, finger-pointing between teams. We profile the locking patterns, find the true offender and fix it without redesigning the schema.
Large DataWindow reports running against the same database that handles user transactions. Performance collapses at month-end. We separate the workloads cleanly.
Measure, isolate, fix, document
Performance work without baseline is theatre. We invest in measurement first and surgical fixes second. Most engagements move a single dial dramatically rather than nudging ten.
1 week
Baseline
Capture real workload: top queries by time, by frequency, by lock waits. Establish numbers we can compare against later. No guessing.
1–2 weeks
Diagnose
Find the actual bottleneck — often surprising. Sometimes it's a missing index; sometimes it's connection pooling; sometimes it's a forgotten loop in PB that fires 10,000 single-row queries.
scoped · weeks
Fix
Surgical changes, one at a time, each measured before and after. Rollback ready for every change. Production unaffected.
1 week
Document
What changed, why, what to monitor going forward, what the next likely bottleneck is. Your DBA inherits a clear picture, not a black box.
What teams ask before they call
Not on the list? Ask us directly — we usually reply within one business day.
Will an Oracle upgrade break PowerBuilder?
Usually no, but the failure modes are specific: character-set differences (especially around AL32UTF8), deprecated PL/SQL features, RETURNING clauses, sequences, JSON support, hint syntax. We test these explicitly before the upgrade rather than discovering them in production. Most upgrades go through cleanly once the risks are mapped.
Can we move from MSSQL to PostgreSQL while keeping PowerBuilder?
Yes, but it's substantial work — and worth scoping seriously before committing. PowerBuilder is database-agnostic, but stored procedures don't port automatically: T-SQL and PL/pgSQL look similar and behave differently. We do the porting properly and ship a regression suite.
How do you tune DataWindow queries without rewriting the UI?
DataWindow queries are generated, but the inputs are under our control: retrieval arguments, filter expressions, sort/group behaviour. Often the fix is in the input, not the query itself. When deeper changes are needed, we use Stored-Procedure DataWindows that hide the change behind a stable interface.
Is connection pooling worth changing?
Almost always yes. PowerBuilder applications classically hold long-lived connections with substantial state. On modern infrastructure (Citrix, RDS, virtualized environments), that pattern silently kills throughput. Switching to a proper pool, with right-sized timeouts, often delivers a 2× improvement on its own.
We're seeing weird character-set issues. Where do we look?
Three places, in order: database character set (NLS_LANG for Oracle, collation for SQL Server), ODBC driver settings, PowerBuilder runtime locale. The bug is almost always at one of those boundaries. We've debugged this enough times to know the order to check.
Database trouble under a PowerBuilder application?
Send a short description: which database, version, the symptom you're seeing, and what's been tried. We'll reply within one business day with a practical next step.