Home | Forums | Contact | Search | Syndication  
 
 [login] [create account]   Sunday, May 19, 2013 
 
Detecting the Version of the Installed SalesLogix OLE DB Provider  
Description:  As you likely know, the connection string for the SalesLogix OLE DB Provider changes for version 6.2 of SalesLogix. Now your custom applications that use a connection via the provider will need to be changed. But what about applications that need to be able to work with both versions - for example a commercial application? Sure, you could release two different versions of your application, but why? This article will look at how you can make your applications smart enought to determine which version of the SalesLogix Provider is installed.

Category:  SalesLogix OLE DB Provider
Author:  Ryan Farley
Submitted:  9/15/2004
   
Stats: 
Article has been read 6528 times

Rating: - 5.0 out of 5 by 4 users
 

Detecting the Version of the Installed SalesLogix OLE DB Provider

As you likely know, the connection string for the SalesLogix OLE DB Provider changes for version 6.2 of SalesLogix. Now your custom applications that use a connection via the provider will need to be changed. But what about applications that need to be able to work with both versions - for example a commercial application? Sure, you could release two different versions of your application, but why? This article will look at how you can make your applications smart enought to determine which version of the SalesLogix Provider is installed.


Background

Building custom applications for SalesLogix requires you to use a connection string via the SalesLogix Provider. When Version 6.2 was released, the connection string format changed which would break applications that use a connection string. If your application might be used by users on both 6.1 and 6.2 you have a few options to think about.
  • Hard code the different connection strings and release two versions of your application (one for the 6.2 users and one for the 6.1 users)
  • Determine at run time which version of the SalesLogix Provider is installed and then use a connection string formatted for that version.
Of course option 2 is the way to go. This allows your application to be dynamic and you don't have the burder of supporting two different versions of your software.


Detecting the Provider Version

It is easy enough to read the registered provider information from the registry to detect the version of the SalesLogix provider at run time and then use the appropriately formatted connection string. Why would we not just check the version of the Sales Client that is installed? Because you might not always have the Sales Client installed, such as in the case of a server application. So we will look in the registry where the provider will be registered and then allow our application to drive on.

This sample C# code will return the version of the SalesLogix provider installed.

using Microsoft.Win32;
//...

public enum SalesLogixVersion
{
    Version62, 
    Version61OrPrior
}

public SalesLogixVersion ProviderVersion 
{
    get
    {
        //We'll default to 6.1
        SalesLogixVersion ver = SalesLogixVersion.Version61OrPrior;

        RegistryKey key = null;
        try
        {
            key = Registry.ClassesRoot.OpenSubKey("SLXNetwork.1");
            if (key != null) ver = SalesLogixVersion.Version61OrPrior;

            key = Registry.ClassesRoot.OpenSubKey("SLXOLEDB.1");
            if (key != null) ver = SalesLogixVersion.Version62;
        }
        finally
        {
            if (key != null) key.Close();
        }
        return ver;
    }
}

Of course, in your application you would use this logic to determine the version of the SalesLogix Provider installed so you can modify the connection string accordingly.

if (ProviderVersion == SalesLogixVersion.Version62)
    // use a version 6.2 formatted connection string 
else 
    // use a version 6.1 or prior connection string 


Wrapping it up

Making your applications smart enough to find out information, such as the version of SalesLogix installed will go a long way with your customers. Not only that but it will free you from having to support multiple versions of the application. Don't do things any other way.

Until next time, happy coding.
-Ryan


Article originally posted at: http://saleslogixblog.com/rfarley/archive/2004/08/06/946.aspx

 

About the Author

  Ryan Farley
(SalesLogix Business Partner)
Customer FX Corporation

I am the creator of slxdeveloper.com. As the developer, architect, chief editor of the slxdeveloper.com site, I attempt to build and support the SalesLogix developer community as much as possible, supporting my fellow business partners and providing a place where companies with SalesLogix can learn more about developing and integrating with SalesLogix.

For my day job, I lead all development efforts for Customer FX Corporation as the Director of Development. I work from my home in Arizona but find myself often in Minnesota. I have worked with SalesLogix since it's version 2.13 release and have architected & developed several large applications & frameworks built on new technologies that make use of SOAP, XML, web & windows services while integrating with SalesLogix. Those who know me understand that I am not someone who enjoys spending time in the Architect. Instead, I try to focus on taking SalesLogix to new levels and keep it up with current industry standards and technological advances.

I have 15+ years of formal programming experience using several languages such as C#, Delphi, Visual Basic, C++, T-SQL, & Java - but C# is my passion. You can read more about my love of programming and non-SalesLogix development articles on my personal weblog on RyanFarley.com, and more SalesLogix related entries on my SalesLogix weblog at CRM Developer.

Check out my new product Outlook2CRM - Easy, customizable, SalesLogix integration for Outlook!

Happy coding.


View online profile for Ryan Farley
 

[ back to top] [ send to a friend]  

Rate This Article you must log-in to rate articles. [login here] 
 
Please log in to rate article.
 

Related Articles 
 - Understanding the SalesLogix 6.2 Connection String - Submitted by: Ryan Farley
 - Understanding the SalesLogix OLE DB Connection String (For versions 6.1 and prior) - Submitted by: Ryan Farley

 

Comments & Discussion you must log-in to add comments. [login here] 
 
Author Article Comments and Discussion
Ted Sturr



Re: Detecting the Version of the Installed SalesLogix OLE DB Provider
Posted: 9/16/2004 7:18:03 AM
This is perfect timing Ryan - when I return from this trip I am on I was going to sit down and work through a strategy to determine the proper connection string, you have saved me a lot of headaches and time.

Thanks again for this GREAT resource.

Ted
 
Ryan Farley

slxdeveloper.com Site Administrator
slxdeveloper.com Forum Top 10 Poster!

Re: Detecting the Version of the Installed SalesLogix OLE DB Provider
Posted: 9/19/2004 10:49:40 PM
Glad it helped Ted!

-Ryan
 
Christian B. Mortensen
 

Re: Detecting the Version of the Installed SalesLogix OLE DB Provider
Posted: 10/17/2005 8:10:41 AM
How can I determine whether the user that login are logging in on a remote database or on the host, given that the user has the possibility to look in on both host and remote?

 
Ryan Farley

slxdeveloper.com Site Administrator
slxdeveloper.com Forum Top 10 Poster!

Re: Detecting the Version of the Installed SalesLogix OLE DB Provider
Posted: 10/17/2005 10:41:41 AM
Christian,

Check the DBTYPE field on the SYSTEMINFO table where SYSTEMINFOID = 'PRIMARY'.

If 1 Then Main database
If 2 Then Remote database (ie: remote user)
If 3 Then Remote Office database

-Ryan
 
 

       Visit the slxdeveloper.com Community Forums!
Not finding the information you need here? Try the forums! Get help from others in the community, share your expertise, get what you need from the slxdeveloper.com community. Go to the forums...
 



 slxdeveloper.com is brought to you courtesy of Ryan Farley & Customer FX Corporation.
 This site, and all contents herein, are Copyright © 2013 Customer FX Corporation. The information and opinions expressed here are not endorsed by Sage Software.

code of conduct | Subscribe to the slxdeveloper.com Latest Article RSS feed
   
 
page cache (param): 5/19/2013 3:42:40 PM