Hi everyone,

Sorry for the off-topic post, but I figured someone here would know the
answer.

I have an application written in DElphi and using DBISAM nicely.

I now have a reason to import data into that from another program.  I
know that the other program installs and sets up a custom ODBC data
source.  It uses Crystal Reports to do it's reporting, and I can see
the data from Crystal.

I can also see the data in a new Delphi project using BDE components to
connect to it.

My problem is that I do not want to have to ship the BDE just to
connect to a simple table for a simple import.

Does anyone know of an ODBC connection package that embeds itself in
your application?  The ODBC stuff is all set up by the other program,
so I just need to conenct to it.

Also, I only need this to work if the other program is installed.  If
it isn't then I want the same EXE to work with no errors.

Any ideas or suggestions people?  Thanks for any help in this matter.

David

PS - I'm using Delphi 7.

"David Strange" <<david at signessentials dot com>> wrote on Thu, 2 Mar 2006 23:07:30 -0500

>
>Hi everyone,
>
>Sorry for the off-topic post, but I figured someone here would know the
>answer.
>
>I have an application written in DElphi and using DBISAM nicely.
>
>I now have a reason to import data into that from another program. I
>know that the other program installs and sets up a custom ODBC data
>source. It uses Crystal Reports to do it's reporting, and I can see
>the data from Crystal.
>
>I can also see the data in a new Delphi project using BDE components to
>connect to it.
>
>My problem is that I do not want to have to ship the BDE just to
>connect to a simple table for a simple import.
>
>Does anyone know of an ODBC connection package that embeds itself in
>your application? The ODBC stuff is all set up by the other program,
>so I just need to conenct to it.
>
>Also, I only need this to work if the other program is installed. If
>it isn't then I want the same EXE to work with no errors.
>
>Any ideas or suggestions people? Thanks for any help in this matter.
>
>David
>
>PS - I'm using Delphi 7.

David


I get confused with all these terms - but this link http://www.webopedia.com/TERM/A/ADO.html - says that "Together with
OLE DB and ODBC, ADO is one of the main components of Microsoft's Universal Data Access (UDA) specification, which is designed to provide a consistent way of accessing data regardless of how the data are structured"

ADO comes free with Delphi and I've used it successfully to strip data out of MSSQL databases and into DBISAM.

Probably hasn't helped!

Cheers

Jeff

--
Jeff Cook
Aspect Systems Ltd
Phone: +64-9-424 5388
Skype: jeffcooknz
www.aspect.co.nz

Thanks Jeff

> I get confused with all these terms

Yeah... me too.  I prefer just knowing about DBISAM ;o)

> - but this link
> http://www.webopedia.com/TERM/A/ADO.html - says that "Together with
> OLE DB and ODBC, ADO is one of the main components of Microsoft's
> Universal Data Access (UDA) specification, which is designed to
> provide a consistent way of accessing data regardless of how the data
> are structured"
>
> ADO comes free with Delphi and I've used it successfully to strip
> data out of MSSQL databases and into DBISAM.
>
> Probably hasn't helped!

I've had a look at that, but I can't see the connection like I can
using the BDE components.  I'll have a better look at it now though.
Maybe I just missed something.

David

Hi David,

Jeff's suggestion is good, I second it. You can use ADO to connect
to ODBC data source if you know its name. If you just drop TADOConnection
component on a form and double click it, you will see connection
string builder. Click on build and select Microsoft OLE DB Provider
for ODBC Driver. Click next and select the data source name on
the next page. That's it. The resulting connection string is:

Provider=MSDASQL.1;Persist Security Info=False;Data Source=DBISAM_TEST

You can also incorporate user name and password if necessary.
I was able to connect instantly on design-time.

Regards,
Michael

David Strange > < wrote:
> Thanks Jeff
>
>> I get confused with all these terms
>
> Yeah... me too.  I prefer just knowing about DBISAM ;o)
>
>> - but this link
>> http://www.webopedia.com/TERM/A/ADO.html - says that "Together with
>> OLE DB and ODBC, ADO is one of the main components of Microsoft's
>> Universal Data Access (UDA) specification, which is designed to
>> provide a consistent way of accessing data regardless of how the data
>> are structured"
>>
>> ADO comes free with Delphi and I've used it successfully to strip
>> data out of MSSQL databases and into DBISAM.
>>
>> Probably hasn't helped!
>
> I've had a look at that, but I can't see the connection like I can
> using the BDE components.  I'll have a better look at it now though.
> Maybe I just missed something.
>
> David

Thanks for the responses Jeff and Michael.

I dug deeper trying to figure out the settings for an ADOConnection and
found out that the ODBC driver connection was via a Microsoft Text
driver (or some such thing).  Then digging deeper and examining the
setup in ODBC configuration I found that the program I am trying to
link to just plops a few tab delimited text files in the root directory
of C: drive.

So problem solved, I can just read those files.

Thanks anyway.

David

David,

If you use memo fields, watch out for the MS ODBC text
drivers. I had problems with long string support with the
text ODBC drivers when I generated text files for mail merge
into word. The problem involves machines with Office 97 or
Office 2000 upgrades from Office 97 that default to using
ODBC for reading text files. I don't know if the bug is in
the ODBC driver itself or in the way Word communicates with
it, so you may want to do some testing if you need to use
long strings.

Sean


David Strange > < wrote:
> Thanks for the responses Jeff and Michael.
>
> I dug deeper trying to figure out the settings for an ADOConnection and
> found out that the ODBC driver connection was via a Microsoft Text
> driver (or some such thing).  Then digging deeper and examining the
> setup in ODBC configuration I found that the program I am trying to
> link to just plops a few tab delimited text files in the root directory
> of C: drive.
>
> So problem solved, I can just read those files.
>
> Thanks anyway.
>
> David
>

Sean McCall wrote:

> David,
>
> If you use memo fields, watch out for the MS ODBC text drivers. I had
> problems with long string support with the text ODBC drivers when I
> generated text files for mail merge into word. The problem involves
> machines with Office 97 or Office 2000 upgrades from Office 97 that
> default to using ODBC for reading text files. I don't know if the bug
> is in the ODBC driver itself or in the way Word communicates with it,
> so you may want to do some testing if you need to use long strings.
>
> Sean

Sean,

Thanks for the tip, but as I discovered that these are tab-delimited
text files that the other program uses, and the fact I just need to
import some of the data, I am just going to read it in as a standard
text file and strip it apart for the bits I need.  No ODBC or data
awareness will be used after all.

David