When it's urgent

"We have an urgent problem, please arrange a Zoom session to resolve it."

Although it's understandable for customers who have an urgent issue with a production system to see Zoom as synonymous with a quick solution, we recommend that instead of focusing on the support channel (Zoom versus phone versus email etc.) you do the following:

If it's urgent, send us a log file.

–Or–

If it's a "Failed to initialise licensing, no valid licences..." error that is preventing a production system from functioning, request a trial license on the problem machine. This is the quickest way of getting you up and running.

Log files — why we need them and how to generate them

When a problem is urgent, you need to determine as quickly as possible if the issue is caused by Easysoft software. If it is, only Easysoft can address the problem. That's why we need a log produced when the error is happening.

(A variation on this theme is when the problem lies with the application or database. ODBC behaviour in applications is often set in stone, for example, some applications are still on ODBC 2.0. The more popular the application, the more users could be affected by changes to the ODBC layer, which may increase the application vendor's reluctance to change the application, even if the ODBC layer is behaving incorrectly when measured against the ODBC specification. A database may change its behaviour when incorrect, but you may have to wait some time for a patch that addresses the issue. Getting a log file is also relevant in both these cases because we may be able to provide a workaround even though the root cause of the problem lies with the application or database. We can provide workarounds for uncomformant applications or databases without affecting existing Easysoft users by adding configuration options that override a driver's default behaviour.)

It's possible to generate log files from both components of the ODBC layer, the driver and the Driver Manager. Ideally, we would want both, but at the very least, send us a driver log. The driver log captures diagnostic information related to the problem and also provides us with information about your setup (operating system, architecture, database version, and so on) which makes it easier for us to reproduce your problem.

Linux and UNIX

To generate a driver log on Linux and UNIX, in your data source in the odbc.ini file, you need the lines:

[MYDSN]
Logging = Yes
LogFile = dir/easysoft_driver.log

To generate a Driver Manager log on Linux and UNIX, in the odbcinst.ini file, you need to add these lines to the top of the file:

[ODBC]
Trace = Yes
TraceFile = dir/unixodbc.log

Important Replace dir with a directory where the user running the ODBC application has permission to write to. For example, /tmp. If writing to an existing log, that user need to have permission to write to the file instead.

Windows

To generate a driver log on Windows, open the relevant data source in ODBC Data Source Administrator. The ODBC driver configuration dialog box will contain a Driver Logging option (or something similarly named) and a box for you to enter the log file path. For example, C:\Windows\Temp\Easysoft_Driver.log.

To generate a Driver Manager log on Windows, in ODBC Data Source Administrator, choose the Tracing tab. Enter a log file path in the space provided. For example, C:\Windows\Temp\Driver_Manager.log. Choose Machine-Wide tracing for all user identities, and then choose Start Tracing Now.

Important You need to specify a log file directory where the user running the ODBC application has permission to write to. If writing to an existing log, that user need to have permission to write to the file instead.

Do this when rolling out production systems

We recommend that even if you're not experiencing any problems, you make sure that you can generate at least a driver log as part of your rollout process. Yes, the gap between doing this and an issue arising may be months or years, in which time, you may forget the procedure, lose the instructions or change personnel. The real purpose is verifying that your application can write a log rather than the process itself — the instructions don't change and are available on the web. Doing this gives you chance to resolve any permissions problems that prevent a log from being generated before any urgent issues arise. (Another reason for not getting a log file is when your application is not getting as far as using the ODBC driver, which can be the case with Oracle Heterogeneous Services, if there's a problem creating a SID for DG4ODBC. For example, if you make a mistake configuring the various .ora files, Oracle Heterogeneous Services does not get as far as loading the ODBC driver and therefore you will not get a driver log file.)

Which changes to a production system affect Easysoft ODBC drivers?

Why email support is compatible with urgent support requests

Although the iterative nature of an email exchange may seem at odds with the quick resolution of an urgent problem, it shouldn't be seen as a poor relation to support channels such as Zoom (which we can and do offer). The gaps between email exchanges give us time to:

Email exchanges give us a log that we can refer back to if another support team member needs to take up the call. Email exchanges also provide a useful record, should you need to retrace your steps in the future.