I've used this technique many times since, often to great effect. A bit of internet research revealed how to explicitly configure the Gateway connection language settings to force the correct language, and the problem was resolved. I verified my new settings exhibited the same behaviour by re-diffing the log files from my newly failing system against the ones I'd been given. Having an area of interest to focus on I was able to very quickly recreate the issue by altering the character set settings of the Oracle database, which I discovered were then passed by default into the gateway and resulted in the incorrect language settings being used on the ODBC connection. With a scan to the end of the file revealing nothing further that appeared interesting, I investigated the character set changes further. I had requested and received full debug tracing from the Oracle gateway application, however I was not overly familiar with the structure of the logs, which contained a number of bespoke parameters and settings. Unfortunately after checking out all of the configuration files and parameters that I knew could cause issues if not set correctly, I'd not got any nearer to the cause of the problem. Having set up a similar environment myself a few weeks before I was well placed to investigate. This is the situation that I found myself in a while ago when a someone found an issue trying to use our software via an Oracle Gateway interface and had encountered an error returning LONG data types. If the installation appears to be sound and the cause of the issue is not obvious, then it can be difficult to know where to look when trying to recreate and diagnose problems. The classic It works on my machine scenario is a common example. As a data warehouse tester friend of mine Ranjit wrote in his blog - being able to visualise key characteristics of information gives is a critical skill in testing in our domain, and here is a great technique to demonstrate this.īoth through my testing work and my role running the technical support I am often faced with investigating why certain operations that work fine in one context will fail to do so in another. It is not immediately obvious why someone working primarily with big data, manipulating huge log files and SQL via command line interfaces, would worry too much about visual elegance. It is this visual element that is most important for my use case. The reason that I choose to use DiffMerge is that I find it has the nicest interface I've found for visually representing differences between files in a clean and simple manner. There are a number of diff tools available. I've started to compile a summary list, which I'll hopefully post sometime soon, but in the meantime I thought I'd do a more detailed post on a fantastic tool by SourceGear called DiffMerge, and how I use it to investigate software problems through the comparison of log files between systems. The problem that I have is that there are so many great tools that help me in my testing and I'd want to do justice to them all with a good level of detail as I did with WinSCP and NotePad++ in this post. This idea was brought back to the forefront of my mind recently when reading this post by Jon Bach on and exchange of tool ideas between Jon and Ajay Balamurugadas. I've been meaning for a while to publish a blog post on tools that I find useful in my day to day testing.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |