ODBC Connection Failed (Linking to an Unknown Data File)

[CH84]

Hi All,

I am fairly new to linking to databases, so please bear with me. As of right now I am working on pushing and pulling settings from a settings file (attempting to automate the process). The manufacturer uses an .rdb file extension, and refers to the file as a database. However, when trying to link to the database I get an error. Typically software producers provide a driver associated with their database files that they produce. The only drivers provided with the software, do not run when opening the settings file. In other words, the program handles the settings with the software without linking to the file. I have tried a trace and everything else I could think of, but no luck. I am thinking that they call this file a database, when in fact it is not.

I have opened up the settings file as a text file to view the formatting. It looks to be comma delimited, and fairly standard. I would just edit the file by opening it up, but the file will be unrecognizable to the settings program afterwards.

I have pulled the data from the file with Interactive SQL “ISQL,” but it just shows up like in the text file, and there does not appear to be an active link. It also shows up in my command line which is unhelpful. When attempting to pull the database information, it actually states that the file is not a database file.

Excuse my lack of understanding, but here are my questions:

1. Is there a driver that will link to any data file, regardless of the formatting?

2. If this is not a database file, and just a comma delimited data file, can I still establish a link to the file by other means?

3. How hard would it be to create a driver that would handle this file?

4. Is it possible that the file does not allow connections to be made to it?

Data:

[R]
ESERDL,"Y"
SRDLCT,"10"
SRDLTM,"2.0"
[T]
NLB1,"NA"
CLB1,"NA"
SLB1,"NA"

Thank you for your help,

CH

 

[JRB-Bldr]

I may not be the best individual to answer your questions, but I have been using ODBC for a number of years.

So here goes my attempts to answer your questions.....

1. 1. Is there a driver that will link to any data file, regardless of the formatting?

Most typically a single ODBC Driver will allow access to any data table (file) within a given specific Database (e.g. M$ SQL Server, MySQL, Informix, etc.).

There is not ONE single ODBC driver which will provide access to ALL Databases and/or other file types.

2. If this is not a database file, and just a comma delimited data file, can I still establish a link to the file by other means?

Generally when you are needing to access data from a file not in a Database (like CSV, TXT, TAB, DAT, etc.) you do not establish a link to it.
Instead your language of choice most often has alternative methods (other than ODBC) to use to read/write the data to those file types.
There are a few exceptions to that (notably Excel files) where an ODBC driver does exist, but generally that is the case.
Regardless, in the vast majority of cases, I would recommend using those alternative methods.

3. How hard would it be to create a driver that would handle this file?

How good are you at writing very low-level code?

I'd recommend not bothering trying to re-invent the wheel when you most likely have alternative methods available to you to access these other forms of data.

4. Is it possible that the file does not allow connections to be made to it?

There are certainly situations where a file (when not in a Database) or data table/file can restrict and/or prevent access.
Some vendor provided proprietary ODBC drivers can restrict data table access.
And other file types may not be available for READ/WRITE access if they are currently in use by other users.
Typically your code has to make allowances for these possible situations and find a way to work regardless.

On a more general note...
The manufacturer uses an .rdb file extension, and refers to the file as a database.

A 'manufacturer' can call anything file type they want anything they want. To them a text file could possibly hold 'data' and be used as such - thereby allowing them to think of it as a data file.

NOTE - a Database is a container of data files, not a file itself - with the exception of some OLD, OLD language terminology where the term was mis-used.

I once found a vendor was using files with the WSD extension which turned out to be an Access Database (MDB) file using a different file extension. In that case, once I discovered that, I used the M$ Access ODBC driver and all went fine.

So just because the vendor uses a RDB file extension, does not mean much by itself. The web lists a variety of possible sources for the RDB file extension. And it may be a 'phony' use of the extension such as I encountered. You should contact the vendor and REQUIRE them to disclose to you the 'database' file type.

The only drivers provided with the software, do not run when opening the settings file

Remember that 'settings' files are typically not very dynamic and therefore are many times not put into a 'true' data table. Generally it is the data which is entered/acquired frequently and/or periodically (the vastly more dynamic data) which goes into the data tables. So there is a distinct possibility that the 2 file types can indeed be different despite similar or same file extensions.

Good Luck,
JRB-Bldr

 

[SkipVought]

You can use an ODBC TEXT DRIVER.

http://msdn.microsoft.com/en-us/library/ms709353.aspx

Skip,
[sub]
Just traded in my old subtlety...
for a NUANCE![/sub]

 

[JRB-Bldr]

I guess that I was not aware of a ODBC TEXT DRIVER

With data possibly appearing within any given TXT, CSV, DAT, etc. file as:
* Comma Delimited
* Quote Comma Delimited
* TAB Delimited
* SDF (Fixed Field Length) format
* With or without a 'header' row
* Etc.
I'd be suspicious of it working on everything I needed.

As soon as you got things to work on one type you would very likely receive a different format the next time and things would once again not work.

With that in mind I'd still recommend going with the language-specific alternative method for reading/writing text files instead of attempting to get an ODBC working for them.

Good Luck,
JRB-Bldr

 

[SkipVought]

As soon as you got things to work on one type you would very likely receive a different format the next time and things would once again not work.

If you read the link, you would see that tere is an INI file that defines the type of delimiter, fields and field types. It is certainly NOT for EVERY text file application. But it is a tool in the toolbox, and I want plenty of tools at my disposal!

Skip,
[sub]
Just traded in my old subtlety...
for a NUANCE![/sub]

 

[CH84]

Thanks for everyones input. It is greatly appreciated. I will keep you posted if I make any significant progress.