TAFC to TAFJ

TAFJ DBTools: The SELECT Replacement Nobody Tells You About

DBTools is the separate TAFJ console you reach for when old TAFC command-line SELECT habits no longer apply. This guide is organised around the tasks support teams actually need: get in, query safely, understand result limits, use script mode, and know when JED is too risky for routine investigation.

For developers and support analysts making the TAFC to TAFJ move

By T24Guru Editorial·Published 5 April 2026·Updated 3 September 2026

Migration

Browse more Migration articles →

The biggest DBTools mistake is treating it as a drop-in copy of the TAFC command line. It is a separate tool with its own launch/configuration, modes, credentials, result-limit behaviour, and direct-editing risk. Learn those differences before a production incident rather than during one.

I need to...	Jump to	Primary caution
Understand what DBTools is	What DBTools actually is	It runs separately from the T24 Browser/application session.
Launch and authenticate	Getting in	Credentials/configuration can be separate from normal T24 sign-on.
Run SQL or JQL	Running queries	Prefer read-only investigation and verify transaction/commit behaviour locally.
Understand truncated results	Result limits	The effective limit is release/session/configuration dependent.
Automate a read-only query	Script mode	Quote/escape shell-sensitive characters and protect credentials/output.
Open a record in JED	JED	Direct editing can bypass normal application validation/audit controls.
Copy a command pattern	Quick reference	Verify syntax against the installed release before relying on it.

What DBTools actually is

DBTools is a standalone TAFJ command-line utility. It is not the same thing as a T24 Browser session, and it is not simply the old TAFC command line with a new name. It is launched from the TAFJ installation and talks to the configured database using the DBTools runtime/configuration for that environment.

Common capabilities include:

SQL mode — run SQL against the underlying database.
JQL mode — use T24/JBASE-style file-oriented commands supported by the installed release.
JED — inspect and, where enabled, directly edit records.

The practical migration mindset change is simple: ad-hoc data investigation moves out of the familiar TAFC command-line workflow into a separate tool with different safety boundaries.

Getting in

A common launch pattern is:

DBTools -u <username> -p <password> -cf <configuration>.properties

Treat this as a pattern, not a universal command line. Launcher names, configuration paths, authentication setup, and optional flags can differ by TAFJ release and local installation. Use the installed environment documentation to confirm the exact form.

Credentials are a separate operational dependency

DBTools authentication may be managed separately from the normal T24 application login. If the environment uses the TAFJ user-management utility, an administrator can create/reset the DBTools account with the locally supported tUserMgntworkflow. Do not assume your Browser credentials will work.

Before go-live, prove that every person expected to use DBTools can launch it against the correct non-production configuration and run an approved read-only query. That rehearsal is more valuable than discovering missing accounts during an incident.

Running queries

SQL mode

In installations that expose the interactive SQL mode described here, switch into SQL mode and run a deliberately narrow query first:

SQL
SELECT RECID FROM FBNK_CURRENCY WHERE RECID = 'GBP'

Prefer explicit columns and selective predicates while investigating. A narrow query proves connectivity and object naming without pulling a large production result set.

Commit behaviour

Do not assume transaction or auto-commit behaviour from another environment. Before any write-capable use, inspect the DBTools session state and local runbook. For routine support investigation, stay read-only unless there is a separately approved change procedure.

JQL mode

JQL mode is useful when you need the file-oriented view rather than raw SQL. Typical read-only patterns include counts and record listing, subject to the syntax supported by the installed release:

JQL
COUNT FBNK_CURRENCY
LIST-ITEM FBNK_CURRENCY WITH RECID = 'GBP'

If SQL and JQL appear to disagree, first check whether you are comparing the same object, company context, selection criteria, and result limits.

The 200-row limit: treat the number as an example, not a rule

Teams often describe DBTools as having a “200-row limit”. That can be an observed default in a particular interactive SQL setup, but it is not safe to present 200 as universal across TAFJ releases, database drivers, sessions, or configuration.

For the interactive SQL mode described by this site, use setup to inspect the effective Max Row Retrieved (SQL) setting where that option exists. If a different mode or release exposes a command such as SET.QUANTITY, verify what that command actually controls before assuming it changes the same limit.

Symptom	Check	Avoid
Exactly N rows returned	Inspect the session/configured SQL retrieval limit.	Assuming the table only contains N rows.
Different row count in another mode	Compare mode, release, configuration, and query criteria.	Changing multiple settings before proving which one applies.
Need a large extract	Use an approved reporting/export path designed for the volume.	Raising an interactive limit indefinitely on a live system.

Result limits protect operators and systems from accidental large retrievals. Change them only with a reason, understand the scope, and restore the normal operating value when the approved task is complete.

Script mode

DBTools can be used non-interactively for repeatable checks where the installed release supports the relevant flags. A synthetic pattern looks like:

DBTools -u <username> -p <password> -s SQL SELECT RECID FROM FBNK_CURRENCY

Shell characters such as * may need quoting or escaping depending on the shell and command construction. More importantly, avoid putting reusable credentials into shell history, scripts, issue comments, or shared logs. Follow the local secret handling and service-account pattern for automation.

For scheduled checks, capture only the output needed for the operational question and protect the resulting log like any other potentially sensitive production evidence.

JED — direct record editing

JED is the DBTools record editor. A common open-record pattern is:

JED FBNK_CURRENCY GBP

The exact editing commands and behaviour should be confirmed against the installed release. The important operational point is not the keystrokes — it is the boundary: direct database/file editing can bypass normal T24 application validation, authorisation, and business-processing paths.

Use JED as an investigation tool by default, not as an incident shortcut. If a direct edit is ever required, it should have an explicit local runbook, approval, backup/recovery position, evidence of the original value, and post-change validation.

If the real problem is an application transaction or OFS request, fix the application path rather than using a direct edit to make the symptom disappear.

The workflow difference

Task	TAFC habit	TAFJ / DBTools mindset
Check a record	Run SELECT from the familiar command line.	Launch the separate tool/configuration and choose SQL/JQL deliberately.
Authenticate	Reuse normal application context.	Prove the DBTools-specific access path before the incident.
Interpret row count	Assume the returned set represents the full result.	Check configured/session result limits before drawing conclusions.
Change data	Use familiar T24 maintenance/application paths.	Prefer application-level change; direct DBTools edits have a different risk/audit boundary.
Repeat a check	Re-enter interactively.	Use a controlled script/read-only command when repeatability is genuinely needed.

Preparation is the mitigation. Set up access, practise the read-only path, document the approved configuration, and make sure the team knows what DBTools can and cannot safely prove before go-live.

Quick reference

These are task patterns to orient an operator. Confirm the exact syntax/flags against the installed TAFJ release and local configuration before relying on them.

Task	Pattern	Safety note
Launch DBTools	`DBTools -u <user> -p <pass> -cf <config>.properties`	Protect credentials and verify the target configuration.
Switch to SQL	`SQL`	Start with a narrow read-only query.
Switch to JQL	`JQL`	Confirm command support in the installed release.
Inspect result limit	`setup` → Max Row Retrieved (SQL), where available	Do not treat a historical 200-row example as universal.
Open a record	`JED <FILENAME> <RECID>`	Investigate read-only unless direct editing is explicitly approved.
Script a SQL check	`DBTools ... -s SQL SELECT ...`	Avoid exposing credentials or sensitive output in scripts/logs.

DBTools vs TAFC SELECT

The important difference is not merely command syntax. DBTools introduces a separate access/configuration boundary and exposes lower-level capabilities that demand more deliberate production controls. Treat it as an operational tool in its own right.

If a SELECT that worked in TAFC appears to return nothing after migration, continue with the focused TAFJ SELECT troubleshooting guiderather than immediately changing DBTools limits or editing data.

Useful next steps

TAFJ Compilation Pipeline Failed SELECT in TAFJ TAFJ Log Locations Descriptor Limitations in TAFJ