Q: What Is Deep Dive Analysis?
A: Deep Dive Analysis is a built-in troubleshooting tool that helps diagnose database connection problems with a Crystal Report. When a report fails to connect, returns no data, or pulls data from the wrong schema or database, this feature gathers far more diagnostic information than a normal Report Runner log. It inspects the report file, your machine's database configuration, and performs targeted tests — then appends everything to the standard Report Runner log file for support to review.
The entire analysis is read-only. It never modifies your report, your database, or any settings on your computer. It only inspects, probes, and logs.
---
Q: When Should I Use Deep Dive Analysis?
A: Use it when:
---
Q: What Information Does Deep Dive Analysis Collect?
A: It collects information in several layers. All output is written to your Report Runner log file in clearly labeled sections.
Report file analysis — loads your .RPT file and examines exactly how Crystal Reports expects to connect: database type, driver, server/DSN/TNS alias, database name, user ID, integrated security setting, every table (including subreports), qualified names vs. engine Location, Crystal version, and more. If the report file itself can't be loaded, the reason is logged and the analysis stops.
Machine environment & connection cross-reference — checks process bitness (32-bit vs 64-bit), scans for installed database software, and verifies whether everything the report asks for actually exists on this machine (e.g., "Does the DSN or TNS alias the report references exist here?"). It also explicitly checks bitness matching for ODBC DSNs — a very common cause of connection failures.
Targeted tests against the report's actual datasource — connects (read-only) to the exact server, DSN, or TNS alias the report uses and tests multiple connection methods.
Crystal runtime verification — re-loads the report, applies your credentials to every table (main report + all subreports), and asks Crystal Reports itself to run VerifyDatabase. This is the most authoritative test of whether the report can actually connect.
Diagnostic verdict (summary) — at the end, a clear summary shows which database families were detected, whether bitness issues were found, whether tests succeeded, and a "top suspected cause" recommendation.
---
Q: What's Database-Specific About The Analysis?
A: Each database gets its own deep dive.
For SQL Server, it checks:
For Oracle, it checks:
For MySQL, it checks:
---
Q: What Happens If I Provide Database Credentials?
A: Credentials are optional. Without them, Deep Dive Analysis still performs the full machine and report inspection — it just can't run actual login tests.
When you supply credentials, it runs read-only authenticated tests:
Only SELECT queries are used. If a report uses integrated security (Windows authentication), targeted SQL Server tests can still run using your Windows identity.
---
Q: How Long Does Deep Dive Analysis Take?
A: Most runs finish in under a minute. The longest parts are disk scans for client DLLs (the tool skips known noisy directories like WindowsApps, WinSxS, and node_modules to stay fast) and TCP probes (each times out after 5 seconds). On machines with many old TNS entries or heavy antivirus activity, the full analysis can take 2–5 minutes.
A "Please Wait" dialog shows progress, and the log includes timing for each major section.
---
Q: Is Anything Sensitive Logged?
A: Safety is a priority. Passwords are always masked. Connection strings are never logged in raw form. Provider error messages are automatically scrubbed for Password= or PWD= values. Configuration files defensively mask any "password" lines.
User IDs, server names, database names, and TNS aliases are logged as-is because support needs them to diagnose the issue. If you're sending the log outside your organization, give it a quick review first — tnsnames.ora content is logged in full.
