Thu, 04 May 2017
When It's Urgent
"We have an urgent problem, please arrange a WebEx (or NetMeeting, TeamViewer and so on) session to resolve it."
Although it's understandable for customers who have an urgent issue with a production system to see WebEx as synonymous with a quick solution, we recommend that instead of focusing on the support channel (WebEx versus phone versus email etc.) you do the following:
If it's urgent, send us a log file.
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, e.g. 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 etc.) 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.
To generate a driver log on Windows, open the relevant data source in ODBC Administrator file. 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. Type 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 are 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 (i.e. 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?
- Changes to the constituent parts of a machine that are relevant to Easysoft licensing. If this stops a production system, contact us for a trial license. This will get you up and running again quickly, whilst the license transfer process for the purchased license runs its course.
- Operating System version changes. Easysoft ODBC drivers are tied to a particular set of operating systems. Upgrading a machine to a different operating system version (or for Linux machines one based on a different version of the kernel) may cause the driver to stop functioning. A new version of the driver with a trial license is the quickest route to getting up and running again.
- Database version changes. Easysoft ODBC drivers may cease to function if the target database is upgraded to a different version. Again, contact us for a newer version of the ODBC driver if this happens, and use a trial license to get going again.
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 WebEx (which we can and do offer). The gaps between email exchanges give us time to:
- Look at support call logs based around similar issues.
- Recreate your set up on a virtual machine.
- Research best practice from the application or database vendor.
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.