Test connection to remote SQL Server Database from an Application server

While aiming to test whether a SQL connection is succeeding between an Application server and a remote Database Server, it is often not possible to install SQL Server Management Studio (SSMS) or Microsoft Command Line Utilities (MsSqlCmdLnUtils) due to the locked down nature of the targets, particularly in test and production environments.

A lightweight approach that worked for me recently, makes use of components that have been a part of windows boxes for a long time, albeit different levels of database driver support as the components have evolved, the Microsoft Data Access Components (MDAC).

MDAC provide a Universal Data Link, which can be configured using a common user interface for specifying connection properties as well as testing the connection.

Data Link properties dialog box

Get started – Create a simple text file

• Simply create a .txt file anywhere on your system

rename the extension to .udl

• Double click the Universal Data Link file (.udl)

We are then presented with the Data Link Properties dialog, which will look very familiar.

Using either Windows Integrated Security or a specific Username / Password combination the connection to the database can be tested.

You can also save your configuration settings you have applied by just selecting ‘OK’ on the properties dialog, useful for reoccurring scenarios, more complex configurations or just as a handy utility for future reference.

Using this approach, i was able to determine very quickly that the password for a test environment database had been changed in just a few minutes.

References

https://en.wikipedia.org/wiki/Microsoft_Data_Access_Components
https://msdn.microsoft.com/en-us/library/e38h511e(v=vs.71).aspx

Checkout some other musings via my blazor.net and azure blog here carlrandall.net

Feel free to contact me via my site AssemblySoft to discuss any ways i can help with your next project or checkout some other musings via my blazor.net and azure blog here carlrandall.net

Instrumentation with Semantic Logging Application Block from Microsoft Enterprise Library 6

Introduction Instrumentation, the process of auditing and logging in your applications, is a vital part of any enterprise solution. When you are developing applications with Service Level Agreements and specific Auditing requirements, logging is a big deal. Add in the complexity of the decoupled nature of the cloud with Service Orientated Architecture, piecing together a clear view of a business process from end to end can be a challenge. Microsoft has recently released the Semantic Logging Application Block ( SLAB ) to the enterprise library. This article will form the first part of a mini-series, detailing the benefits, pitfalls and examples of how to make use of it in your enterprise. Although new to the Enterprise Library, Semantic logging is not a new concept. It has been adopted for years under different names such as "structured logging", "strongly typed logging" and "schematised logging" to name a few. What is it? SLAB inherits event

Azure Devops - Pull Request Merge Conflicts

Before a Git pull request can complete, any conflicts with the target branch must be resolved. Out of the box, at the time of writing this article, Azure DevOps requires this to be resolved locally. Following best practices to not allow direct commits to our release/master branches further exasperates the problem as we need to effectively clone the branch or go with a rebase approach, both of which break the natural flow of resolving the conflicts as part of the pull request. With this extension, from the Microsoft DevLabs team via the Marketplace, you can resolve these conflicts online, as part of the pull request process, instead of being forced to break flow and resolve locally. Online Experience After adding the extension the new conflicts tab is visible which enables conflict resolution in the familiar side by side review page as shown below: Really nice extension, which should make resolving merge conflicts a much more straightforward part of the DevOps

Windows Azure Storage Emulator failed to install

CodeProject Windows Azure Storage Emulator failed to install When attempting to install a new version of the Azure Storage Emulator either as a separate installation package or automatically as part of an Azure SDK update, you may run into an error message which states the storage emulator has failed to install. This can occur using the Web Platform Installer (WebPI), NuGet Package Manager or when performing the install manually. Below is the message received using the WebPI. Storage Emulator Background (optional reading) The windows azure storage emulator executable lives under the Microsoft SDKs directory as shown below: Configuration If we take a quick look inside the WAStorageEmulator.exe.config file we can see each of the storage services pointing to local service endpoints. <StorageEmulatorConfig> <services> <service name=" Blob " url="http://127.0.0.1:10000/"/> <service

.Net Development, Azure, DevOps, Ideas and Life...

Search This Blog