Ray Thompson

Subscribe to Ray Thompson: eMailAlertsEmail Alerts
Get Ray Thompson: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Related Topics: ColdFusion on Ulitzer

CFDJ: Article

ColdFusion Techniques: Test & Excel ODBC

ColdFusion Techniques: Test & Excel ODBC

Recently I needed to create an ODBC source that would allow an application to read and write from a text file. An obvious question is: Why would I use ODBC to read from and write to a text file? After all, ColdFusion supports this easily using the <CFFILE> tag. You'd be right if you were talking about a purchased copy of ColdFusion. My requirements involved ColdFusion Express, which doesn't support the <CFFILE> tag.

Unfortunately, there's little, dare I say no, documentation on how to use ODBC against text files. There was no information in the CF manuals, nothing on Allaires Web site, and nothing in the ODBC documentation from Microsoft.

On the surface it seemed simple. But it wasn't. There were some surprises along the way. Eventually the mystery was solved, and I was able to read from and write to a text file. In the process I also decided to explore reading from and writing to an Excel spreadsheet directly using the Microsoft ODBC driver.

The Situation Defined
As I explained, the application required the use of ColdFusion Express. This is the free version from Allaire that can be downloaded from their Web site. It has many of the capabilities of the full version. However, there are limits, and one was the lack of support for directly reading from and writing to text files. And, as the <CFFILE> tag wasn't available, I needed a method to access information in a text file and output information into another text file.

This prompted the search for documentation. It's probably somewhere on the Web, but I couldnt find it easily. Even a question posted in the developer conference failed to produce a timely answer to my needs. So I set off on my own.

Defining the Source
The first thing to do was define an ODBC source for the text files. I created a directory and placed a text file in it. The contents of the file are shown in Figure 1. Then I brought up the CF Administrator and created an ODBC source selecting the text file. The connection wouldnt verify. Okay, so step back, think, and perhaps look more closely at the screen in the CF Administrator.

The CF Administrator screen clearly says "database directory." And there's a box on the CF Administrator screen that says "Extensions List" and has the values "asc,csv,tab,txt" listed in the box. I changed the data source to point to the directory, then put "txt" in the Extensions List box. The connection now verified correctly. This indicates that the ODBC connection must point to a DIRECTORY that contains the text file or files. The "Extensions List" needs to contain the extension of the file or files desired. Adding additional extensions separated by commas can process multiple types of files.

Accessing the Data
Now it was time to try to access the data in the text file that was placed in the directory. I was clueless about how the SQL would be constructed to access the data, so some trial and error was needed.

I guessed correctly that the table name would be the name of the text file by virtue of the ODBC setup in the CF Administrator pointing to a directory instead of a file. Id placed two records in the table with the data comma-delimited as that seems to be a common method of separating text data. I wrote a small script to access the file, which did nothing but select data from the file using only the file name as the table name. It returned an ODBC error and failed to work. I then added the extension of the file to the table name, making the SQL Select * from address.txt. That was successful, so it was obvious that the fully qualified file name is required even though "txt" was specified in the ODBC setup.

The next thing was to see the names of the columns that were returned from the query. I knew that the variable query-name.ColumnList, where queryname is the name of the query, contains a list of column names returned from the query. Since Id selected all columns, this variable would show me all the columns that were returned.

I was pleasantly surprised to find that the column names consisted of the comma-delimited values in the first record. A little experimentation showed that column names could have spaces in them as long as they had brackets around them in the query. For example, a column name of First Name would be [First Name] in the SQL for the query.

I then extended the script to output the data that was in the text file. It appeared as expected, with data from the text file starting at the second row as data. A comma was needed between each data field in the text file. I also discovered that if your data contains commas, then simply surround each field with double quotation marks. If your data contains double quote marks, then escape the double quote marks by placing two double quote marks in a row. The problem of reading in data from a text file was solved. The first row is the column name, commas separate the data, and the table name is the fully qualified name of the file with the extension. It was even possible to select only specific rows by using a WHERE clause in the query.

Outputting the Data
Now it was time to create data in a text file using the ODBC driver. Since I already knew that the column names would be placed in the first row of the table, I felt it should be easy to create a file.

The first thing was to create a file with the proper headings, which I could have done by creating the file with just the column names using any standard text editor. But the idea was to make the entire process automatic. I looked for clues in "Help" for MS Access and found some information on creating a table. The code for creating a table is shown in Listing 1. For this example I created a file with text, numeric, and date fields. I don't know if this really matters for a text file, but it certainly helps to document what you're trying to create.

Next, I wrote a small script to place data in the text file. The query was the same as would be used for any "classic" database. After running the script I looked at the file with a text editor, and the data was in the file almost as expected. The text data was always surrounded by double quotes even though they were not specified when the data was written. For the numeric fields I was never able to figure out how to specify the number of decimal places. You can use NUMBER for a field type and get a field with two decimal places. The result of the code is shown in Listing 2.

At this point I had all the information I needed to create a text file using an ODBC driver. The last piece of information was how to eliminate the file if it existed. Any attempt to run the SQL code that created the file would cause an exception if the file (or table) already existed. Since CF Express doesn't support the CFFILE tag, another method had to be devised to delete a file. Id already used ODBC to create a table, so why not use ODBC to delete one? It was certainly worth a try.

I used the CF tag <CFIF FileExists()> to look for the presence of the file (or table) and, if it existed, then use some SQL to delete it. The result was the code in Listing 3. If the file (or table) existed, it would be deleted using the DROP SQL command; it could then be re-created. Note: When using the FileExists() function, it's necessary to fully qualify the file (or table) name with the drive and directory.

Notable Limitations
One thing you cant do with ODBC is update the data in the file. You cant use the UPDATE SQL or DELETE SQL commands; all you can do is INSERT data. And any inserts are placed at the end of the existing data. So you can add to a text file, but that's about it. If you really needed to update the data, youd have to use two tables - reading from one table, then inserting into another. This would be tedious.

I also observed that the process of writing the file was extremely slow: it took almost 45 seconds to write 100 records to the file. This was done on a Pentium 450 with ColdFusion and the ODBC source on the same system. (This was a top-notch system two year's ago; now it's low end.) This Isn't something youd want to use for large volumes of data. Reading the data was reasonably quick, but writing was painfully slow.

This did accomplish the goal of allowing the reading and writing of text files with ColdFusion Express.

Excel Data Source
With the problems of text files out of the way it was time to turn my attention to discovering how to use an MS Excel file as a data source. Fortunately, I had some documentation on how to use MS Excel as an ODBC data source, so this should have been easy. Unfortunately, the documentation was incorrect - the examples it gave wouldnt work.

Now, this may be due to the version of Excel Im using. The Administrator clearly only allows files created with Excel version 3.0, 4.0, or 5.0. The only version I had was Excel 2000, and I was using the "Save As" option to save the file as Excel 5.0. Regardless, I couldnt get CF to work according to the example.

Setting up the data source was no problem, and unlike a text source that points to a directory, the data source for Excel points to a file. This implies that the data to be used as tables is contained within the Excel file.

The example I had says that you must have a data sheet with a name that contains a dollar sign ($) as the last character. You then use this name as the table name in the query and place it in quotes. Well , it just flat out wouldnt work. I tried removing the trailing dollar sign from the sheet name. I tried using single quotes and double quotes. I removed the trailing dollar in the query. Every combination I tried failed for syntax error in the query or not being able to find the table.

I then highlighted the data in the sheet and gave it a name by using the menu items "Insert, Name, Define" and giving the area a name called "Staff." That didn't work either. I then changed the name of the sheet to "Staff." That worked. Apparently you have to have the sheet named what you want your table named, and you have to have the area defined in your spreadsheet that defines the area. I was able to run a simple query selecting all the data. I used the same data as was used for the text ODBC (see Figure 1) and the same query (changing the table name) and output (see Listing 4). The column names were properly retrieved. An interesting side effect is that the column names were returned in alphabetical order.

Formatting on the cells doesn't seem to matter, as the ODBC driver makes it's own decisions about the data. In the case of the zip code, Excel was informed that it contained text data. Yet when the data was returned from the query it clearly considered the zip code to be a number.

I then expanded the data by one column but didn't change the area defined by the name "Staff." The query still worked, but the additional data didn't appear. Only when I expanded the defined area to include the new column did the new information appear.

From all of this it was obvious that the sheet name is the table name, and you must have an area defined on your sheet that encompasses all the required data. As in the text ODBC, the first row is considered to contain the names of the columns for the data.

When defining the data source for Excel in the CF Administrator there's a field called "Rows to Scan." I have no idea what this field represents. I originally thought it was the maximum rows to be returned, but that's not what it does.

I should also point out that if the defined area contains blank rows, then they are also returned. The named area on the spreadsheet is whats always returned when doing the query. Writing to Excel

Now it was time to see how to write data to an Excel spreadsheet. I used the code shown in Listing 1 that was used in the text example. I changed the table name and removed the .txt extension. The code ran with no errors. Time to open the spreadsheet and see what happened.

The data appeared in the Excel spreadsheet as a sheet within the file. There was a new page in the file called "MyTable," which is the table name I created. There was also a named area in the spreadsheet called "MyTable" that exactly matched the amount of data that would have been created. This made sense, as that was the case when reading. The sheet name and the named area on the sheet need to be the same. The data that appeared is shown in Listing 2.

I ran the code again and an error was generated when creating the table. Since the table existed, this was reasonable. I removed the create table code to see what would happen and ran the script.

Another error was produced, informing me that I couldnt expand the named range. It seems that once the data has been inserted into the spreadsheet it can no longer be changed. You cant add to or update the data, and you cant delete the data unless you delete the table using the code shown in Listing 5.

It took 1.8 seconds to insert 500 rows into the Excel spreadsheet. This is considerably faster than writing to a text file.

What Good Is It?
By being able to create a text file I was able to create the data needed in Cold- Fusion Express, even though it doesn't support the <CFFILE> tag. It was slow and should be used in extreme cases, which this was. Using a text file as an ODBC source would allow the reading of data with CF Express. For the "real" version of ColdFusion, the <CFFILE> tag is the obvious choice.

The capability to write to an Excel spreadsheet could be useful. You could create data for a client in Excel format, then deliver the file using the <CFCONTENT> tag. By wrapping the table delete with a simple <CFTRY> and <CFCATCH> tag, the attempt to delete a nonexistent table could be easily handled.

Even then Id think it would be better to just create a text file with comma-delimited values, name the file with .CSV extension, and deliver it to the client if you wanted to create a single file only.

But consider if you need to deliver multiple files that are going to be imported into Excel. I think it would be better to create the multiple files using an Excel ODBC connection and create multiple tables (sheets) in a single Excel file, then transfer that file using <CFCONTENT>. The client will receive only a single file but with multiple sheets. This could be useful in some circumstances.

Wrapping It Up
The need to read from and write to text files using ColdFusion Express made me explore how to do so within it's limits. The ability to use an ODBC source pointing to the text file seemed to be the answer. The process does work; however, performance is fairly poor. But it can fill a need.

After finding out about the text ODBC capabilities, I decided to explore using Excel as a data source. It was possible and did work. The documentation I had for Excel was incorrect and some experimentation was required to find the solution. The information for text files as a source was not to be found. Now that I've written about this, I suppose someone will come forward and point me to it.

The process is so slow when writing the data, making it painful except for the smallest files and when no other solution is available. Even so, it was an interesting exploration into the capabilities and limitations of using text files and Excel as ODBC sources for ColdFusion.

More Stories By Ray Thompson

Ray Thompson is employed by Q Systems in Oak Ridge, Tennessee, a leading developer of Web-based applications. Ray has over 30 year's of experience in information systems and has been involved in many aspects of systems design, deployment, and management, ranging from "big iron" to desktops.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.