Setting up ODBC, Part 2 Robert Abram

Size: px

Start display at page:

Download "Setting up ODBC, Part 2 Robert Abram"

Randell Marcus McBride
5 years ago
Views:

1 Seite 1 von 7 Issue Date: FoxTalk October 2000 Setting up ODBC, Part 2 Robert Abram rob_abram@smartfella.com In this second article of a series about setting up ODBC connections programmaticly through FoxPro, Robert Abram explains some additional features of ODBC DSN configuration that can be used as part of an automated setup process. First, I would like to start off by letting those of you who have used the information from the last article ("Setting Up ODBC Connections for the Client User," May 2000) know that the function SQLGetInstalledDrivers has been depreciated (or at least fails with a GPF in almost all cases) in all versions of Windows I would also like to thank Doug Dodge for first bringing this fact to my attention. If you want to use SQLGetInstalledDrivers, you should check the operating system version with the FoxPro OS() command. The OS() command will return "Windows 5.00" if the operating system is Windows I would like to expand on my first ODBC article and explain some other features of ODBC DSN configuration. What I'll try to do is take the first article and add error checking, multiple DSN configurations, and explain how I used all of that in a networked application that can connect to multiple SQL Servers and multiple Databases. Wish me luck here. ODBC error checking Many people have asked me how to get error information when a ODBC Installer API call function fails. The following code should be added to your application and called immediately after any ODBC installer API call that doesn't return a 0 or 1 (SQL_SUCCESS or SQL_SUCCESS_WITH_INFO respectively): PROCEDURE WriteODBCError LOCAL lh_file, lc_odbcerrortext, ln_odbcerrorno, ; ln_odbcerrorindex, ln_odbctextsize, fresult, ; ln_retodbctextsize, lc_ret lh_file = FOPEN("c:\odbc_err.txt", 1) lc_ret = CHR(13) + CHR(10) DECLARE Integer SQLInstallerError IN odbccp32.dll ; Integer, Integer, IF lh_file < 1 lh_file = FCREATE("c:\odbc_err.txt", 0) IF lh_file > 0 FWRITE(lh_file, REPLICATE('*', 60) + lc_ret) FWRITE(lh_file, PADR("* SQL ERROR LOG OPENNED", ; 59) + '*' + lc_ret) FWRITE(lh_file, REPLICATE('*', 60) + lc_ret) IF lh_file > 0 ln_odbcerrorno = 1 ln_odbcerrorindex = 1 fresult = 0 FWRITE(lh_file, "*** ODBC Error Entry : Date '" + ; ALLTRIM(TTOC(DATETIME())) + "' ***" + lc_ret) * There can be up to 8 error messages from one error. DO WHILE fresult!= SQL_NO_DATA AND ; ln_odbcerrorindex < 9 lc_odbcerrortext = SPACE(500) ln_odbctextsize = 0 ln_retodbctextsize = 0 fresult = ; IF fresult = SQL_NO_DATA EXIT IF ln_retodbctextsize > 0 ln_odbctextsize = ln_retodbctextsize + 1 lc_odbcerrortext = SPACE(ln_ODBCTextSize) fresult = ;

2 Seite 2 von 7 IF fresult = SQL_NO_DATA EXIT IF LEFT(lc_ODBCErrorText, 1)!= CHR(0) AND ; LEN(ALLTRIM(lc_ODBCErrorText)) > 0 lc_odbcerrortext = LEFT(lc_ODBCErrorText, ; AT(CHR(0), lc_odbcerrortext)) FWRITE(lh_file, "Error No: (" + ; ALLTRIM(STR(ln_ODBCErrorNo)) + ; ") Error Msg: '" + lc_odbcerrortext + ; "'" + lc_ret) ln_odbcerrorindex = ln_odbcerrorindex + 1 ENDDO FWRITE(lh_file, "* ODBC End Entry *" + lc_ret) FClose(lh_file) ENDPROC The WriteODBCError will create and append errors to a file called "c:\odbc_err.txt." If a call to an ODBC configuration API fails, there might be multiple errors (up to eight at a time.) The WriteODBCError function will write out all errors generated from an API call. A plan for ODBC configuration and application startup At this point, I'm going to give you a list of steps that I used to start the application. There are several hoops to jump through, but the process works beautifully. Then I'll explain how each of the steps works and the reasoning behind why I completed each step. Although my application requires such steps to start and stop, not all of these would be required for smaller applications: 1. Declare ODBC and public variables. 2. Read ODBC configuration file for single or multiple connections. 3. Allow the user to pick a connection if there are multiple connections available. 4. Try connecting to the database server. 5. Copy FoxPro DBC with views to a local temporary directory. 6. Modify a DBC's connection information to reflect the correct ODBC DSN. 7. Start the application. 8. Close Application and Clean up. Step 1 Declare ODBC and public variables The following are all of the ODBC defines that I use. I put these at the top of my MAIN.PRG file for the application: #define ODBC_ADD_DSN 1 #define ODBC_CONFIG_DSN 2 #define ODBC_REMOVE_DSN 3 #define ODBC_ADD_SYS_DSN 4 #define ODBC_CONFIG_SYS_DSN 5 #define ODBC_REMOVE_SYS_DSN 6 #define ODBC_REMOVE_DEFAULT_DSN 7 #define SQL_NO_DATA 100 #define SQL_SUCCESS_WITH_INFO 1 #define SQL_SUCCESS 0 #define SQL_ERROR -1 The public variables I use for information on the current ODBC connection and application temporary directories are: PUBLIC gdir_start, gdir_temp, gdir_libs, gdir_data, ; g_server, g_database, g_odbcconn, ; g_dbuser, g_dbpassword, ; The defines are used by the various SQLxxxxxx functions that are called in different parts of the setup process. The public variables gdir_start, gdir_temp, gdir_libs, gdir_data are used to hold the paths to various file locations used by the application. The variables g_xxxxxx are used to hold the ODBC connection information. The public variable g_odbcconn holds the name of the ODBC DSN and can be used in the SQLConnect function for SQL pass through statements. I'll explain in Step 4 how to gather the information in the g_xxxxxx variables. In Step 5, I'll explain how to setup temporary directories and store the information in the gdir_xxxxx variables. Step 2 Read ODBC configuration file I mentioned the use of a configuration file that holds information about multiple DSN connections in my previous article. I used ODBC File DSN to create the initial file. Many people have asked me where can they find out what the ODBC connection

3 Seite 3 von 7 parameters and values can be. Creating a ODBC File DSN and then editing that file with notepad will help you find out what the parameters and values should be for an ODBC DSN connection. The application I'm working on is a network application and is executed on the server. So I created a special sub-directory that holds the configuration file. All major network operating systems allow for reading in a directory and a file, but no browsing, deleting, or modifing of files in that directory. That way, while the configuration file can only be seen and changed by an authorized person, FoxPro is allowed to read the file. The special directory is relative to the directory that contains the executable, so I use the command gdir_start = SYS(5) + CurDir() to get the starting drive letter and directory and then add the special directory and configuration file to that. The configuration file used by the application can have multiple connection information in the same file. The file created by a ODBC File DSN is identical to a standard Windows INI file. To add multiple connections to the configuration file, you just need to have a different section heading label (for more information, please read up on Windows INI files). The following example shows a brief sample of what I'm talking about: [ODBC] database=bigdatabase server=bigserver... [ODBC_2] database=smalldatabase server=smallserver... You can add your own properties to each configuration in the file. For example, you could add the property "shortdesc=a description of the dsn." Your application could do some branch logic based on extra parameters in each configuration. To read the information in the configuration file, I'm going to use the SQLReadFileDSN function. The declaration for SQLReadFileDSN is as follows: DECLARE Integer SQLReadFileDSN in odbccp32.dll ; ; Short, The SQLReadFileDSN function can be used to find out how many and what the section names are, what properties are contained in a section, and, finally, what the value for a property is. I'm only going to briefly show examples of how to use this API function. A detailed example will be in the file ODBCFUNC.PRG available in the accompanying Download file. The parameters for the SQLReadFileDSN function are as follows: 1. Configuration file name. 2. Section Heading. 3. Property or key. 4. Return string buffer. 5. Return string buffer size. 6. Actual bytes returned in string buffer. The first example is how to return the section headers from the configuration file. In the short preceding example, there are two sections: ODBC and ODBC_2. Variables are needed to use with the function call they should be declared like so: lc_file = "test.dsn" + CHR(0) lc_section = "ODBC_2" + CHR(0) lc_property = "server" + CHR(0) lc_buffer = SPACE(200) ln_ret_size = 0 The preceding example shows how to get the section heading names. Note the " 0" as the second and third parameter. This tells the function that you're expecting the section names to be returned. That's the difference between each use of the SQLReadFileDSN API function: fresult = SQLReadFileDSN(@lc_file, 0, ; IF fresult!= SQL_SUCCESS AND ; fresult!= SQL_SUCCESS_WITH_INFO WriteODBCError() lc_buffer = ALLTRIM(lc_buffer)

4 Seite 4 von 7 The lc_buffer should contain the following text: ODBC;ODBC_2;. Each section name will be terminated by a semi-colon. The next example returns all of the properties or keys under a section: fresult = ; The lc_buffer should contain a list of property names listed under the section "ODBC_2." Again, each item is terminated with a semi-colon. The last example will return the value of a property under a section: fresult = ; LEN(lc_buffer, The lc_buffer should contain the text "smallserver." Note: when a property value is returned, it's already terminated with a CHR(0). So you can loop through all of the properties in a section and append them together in a string to use in the SQLConfigure DataSource API function. My application runs through this process each time the user starts the application. This allows changes to the configuration at any time without having to run to each user's machine, and permits the setup of a central configuration allowing for connections to all remote databases. This way, the Help desk can connect directly to the remote user's database and to see exactly what the user is viewing. Yes, a remote connection to someone's database is allowed in my case, as long as the remote database administrator permits it. Step 3 Letting the user pick a connection This step can be bypassed if there's only one connection for the user. In the application I'm working on, there are instances of users needing to connect to one set of data or another. Also, this lets the Help desk connect to the remote databases as I explained before. When there are multiple connections to pick from, I parse the configuration file into an array and show a list of connections in a list box on a splash form as the application loads. After the user picks from the list, I then use the information in the array for that connection to make the connection to the database. Step 4 Try and connect to the database This topic was mostly covered in the first ODBC article. If you haven't read that article yet, I suggest getting your hands on a copy of the May issue of FoxTalk, or visit the FoxTalk Web site. After the successful connection to the database with the FoxPro SQLConnect function, I fill the global variables initialized in Step 1. Now it's time to explain what each of the public variables hold: g_odbcconn: Holds the name of the ODBC DSN created. I use the SYS(2015) function to get a unique name for the DSN. I need the DSN name stored to delete the DSN connection when the application exits. g_server: This holds the name or IP address of the SQL Server. g_database: This holds the name of the database the application is connecting to. g_dbuser: This is the userid that is required by the SQL Server to connect with. g_dbpassword: This is the password that is required by the SQL Server to connect with. You might wonder why I store the server, database, userid, and password. I store them for two particular reasons. One, if the SQL Server stops while in the middle of the application, I can stop and poll the SQL Server with SQLConnect to see when the server is back up without halting the application. Two, in the application I'm working on, the users have a need to disconnect from one database and connect to another database without halting the application. This second reason supports the application's legacy code requirements. Step 5 Creating and using temporary directories I use temporary directories to overcome some of the pitfalls in a FoxPro DBC. Some of you veteran FoxPro programmers will quickly recognize these problems. Part 1 The problem The problem with configuring an ODBC DSN at runtime for a remote database is subtle one. For a FoxPro DBC to connect to a remote database, there has to be connection information in the DBC. That information in the DBC describes the ODBC DSN that should exist on the local machine. My problem was that I need, in some instances, to connect to multiple databases at the same time. I also need to allow the remote database administrators to have control over the userid and password to connect to the SQL Server. As a result, the information in the DBC connection record probably won't be compatible with the ODBC DSN connection information.

5 Seite 5 von 7 To update the connection information in the FoxPro DBC, you can use the DELETE CONNECTION and CREATE CONNECTION FoxPro functions. These functions only work if you have exclusive control of the DBC. Once a user opens the shared database, exclusive control is no longer possible. To allow connections to multiple databases, I create the name of the ODBC DSN using the FoxPro SYS(2015) function. Since the SYS(2015) function returns a unique name, it will be different than the DSN that was used in the Connection information stored in the FoxPro DBC. Part 2 The solution The solution to the problem is to create some temporary directories and make a copy of the dbc to be used, store it on the local machine while the application is running, and then clean it when the application exits. This method lets you modify the connection information in the FoxPro DBC at any time needed. To create the temporary directories, I use the following code: * Remote Machine application start directory. gdir_start = SYS(5) + CurDir() * Local machine temporary directory gdir_temp = SYS(2023) + "\" + SYS(2015) gdir_libs = gdir_temp + "\libs" gdir_data = gdir_temp + "\data" MD &gdir_temp MD &gdir_libs MD &gdir_data To copy the files, I use something like this: PROCEDURE CopySystemFiles LOCAL lc_sysdatadir, lc_syslibsdir, ; lc_tempdatadir, lc_templibsdir, fresult fresult =.T. ON ERROR fresult =.F. lc_sysdatadir = gdir_start + "\Views\*.*" lc_syslibsdir = gdir_start + "\Libraries\*.*" lc_tempdatadir = gdir_data + "\*.*" lc_templibsdir = gdir_libs + "\*.*" COPY FILE &lc_sysdatadir TO &lc_tempdatadir COPY FILE &lc_syslibsdir TO &lc_templibsdir ON ERROR IF fresult =.F. RETURN.F. And to clean up the temporary directories, I use the following: CLOSE DATABASES ALL SET CLASSLIB TO SET PROCEDURE TO lc_gdir_temp = gdir_temp + "\*.*" lc_gdir_libs = gdir_libs + "\*.*" lc_gdir_data = gdir_data + "\*.*" DELETE FILE &lc_gdir_libs DELETE FILE &lc_gdir_data DELETE FILE &lc_gdir_temp RD &gdir_libs RD &gdir_data RD &gdir_temp You should be able to see where you would put each section of code. Actually, in my code, each section is a separate function. I only showed the complete code for the CopySystemFiles function, because each of the other two sections is almost identical for the error trapping. You should also notice that the remote file directories are named \Views and \Libraries. The local directories are named \Libs and \Data. This is to overcome the FoxPro habit of remembering where something was last opened, instead of where I want something to be opened. Then I set the FoxPro PATH environment to the correct directories. This is how I set my PATH. You should notice that some things are left on the network server and some are local:

6 Seite 6 von 7 SET PATH TO gdir_start + ";" + ; gdir_temp + ";" + ; gdir_libs + ";" + ; gdir_data + ";" + ; gdir_start + "Include;" + ; gdir_start + "Reports;" + ; gdir_start + "Help;" + ; gdir_start + "Forms;" + ; gdir_start + "Menus;" + ; gdir_start + "Progs" A call to OPEN DATABASE xyz_data EXCLUSIVE is okay now since a copy of the database is available locally on the client machine. Step 6 Modifying a DBC's connection information Once the temporary directories have been created and the files have been copied to the temp directories, the following code will set the DBC's connection information: OPEN DATABASE xyz_data EXCLUSIVE SET DATABASE TO xyz_data * Remove the old Connection DELETE CONNECTION odbc_conn * Add the new Connection CREATE CONNECTION odbc_conn DATASOURCE ; g_odbcconn USERID g_dbuser PASSWORD g_dbpassword Changing the connection information can be done at anytime as long as no one else is using the database. Step 7 Starting the application The application I'm working on is based on a framework. At this point, I start the application by creating an instance of the application manager and starting the initial menu form. Since the FoxPro database is already open and ready to go, the application starts just fine. Step 8 Closing the application and clean up There are three things to clean up here. First, the ODBC connection needs to be attended to. Close all open files and the database, and then delete all of the temporary files and directories that you created. To clean up the ODBC data source, use the following code: PROCEDURE DeleteODBCConnection LPARAMETERS lc_odbcdsn LOCAL lc_odbcdriver, lc_settings DECLARE Integer SQLConfigDataSource IN ; odbccp32 Integer, Short, lc_odbcdriver = "SQL Server" + CHR(0) lc_settings = "DSN=" + g_odbcconn + CHR(0) IF SQLConfigDataSource(0, ; < 1 WriteODBCError() RETURN.F. I use the following code to close everything up and clean the temporary directories and files I created: PROCEDURE DeleteTemporaryDirectories LOCAL fresult, lc_gdir_temp, lc_gdir_libs, lc_gdir_data IF TYPE("gdir_temp")!= 'C' fresult =.T. ON ERROR fresult =.F. CLOSE DATABASES ALL SET CLASSLIB TO SET PROCEDURE TO

7 Seite 7 von 7 lc_gdir_temp = gdir_temp + "\*.*" lc_gdir_libs = gdir_libs + "\*.*" lc_gdir_data = gdir_data + "\*.*" DELETE FILE &lc_gdir_libs DELETE FILE &lc_gdir_data DELETE FILE &lc_gdir_temp RD &gdir_libs RD &gdir_data RD &gdir_temp ON ERROR IF fresult =.F. MessageBox("Unable to Remove Temporary Directories. " + ; "Application not closing clean.", ; 48, "Fatal Error Message") RETURN.F. Conclusion I don't believe that all of the information given in this article applies to every application, and not every programmer needs all of these steps. But I do believe there are some good tips that any programmer, regardless of situation or skill level, can use hopefully, you were able to glean something from this. I'm grateful for the responses that I received from the first ODBC article, and I was glad to be of help.

It Might Be Valid, But It's Still Wrong Paul Maskens and Andy Kramek

Seite 1 von 5 Issue Date: FoxTalk July 2000 It Might Be Valid, But It's Still Wrong Paul Maskens and Andy Kramek This month, Paul Maskens and Andy Kramek discuss the problems of validating data entry.