Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Programming: ODBC Connection

4 views
Skip to first unread message

Chris

unread,
Mar 25, 2009, 11:38:15 AM3/25/09
to
Hi Community,

First, I wasn't sure how to describe the question, so a sad Subject line was
created.
Second, I come from a LAN/Hardware side of Information Technology but am
dabling with some basic VB.NET and Access DB programming to accomplish a few
things for our Retail side.

We are currently using an application that uses a C-ISAM db. We can pay for
Transoft ODBC licenses to connect to this db - which we have a few.

What I have done for a project is imported 3 tables into an Acces DB and
have designed a small VB app around it. This works great. The challenge is I
need to import the tables frequently and distribute to another network
resource. This takes time.

What I want to do is:

* Create a program/script on our server that uses the Transoft ODBC to
connect to the DSN, import the 3 tables I need to an Access DB.
* Copy the Access DB to a path on the network or to a specific machine
on a daily basis.

Is this possible to script or write something in VB.Net?

Ralph

unread,
Mar 25, 2009, 4:26:08 PM3/25/09
to

"Chris" <Ch...@discussions.microsoft.com> wrote in message
news:C8309370-299C-4F83...@microsoft.com...

Yes it is.

However, this newsgroup is for the original VB platform. You need to post in
a VB.Net or dotNet newsgroup. They all have ".dotNet." or ".vs." in their
title.
(Not trying to 'run you off'. In any of those groups you will find more ppl
who use the dotNet products, thus more likely to get help specific for your
development platform.)

[Also while you are there you might explain a bit more on why you want to
share a mdb file? Not saying there is anything wrong with that if that is
what you need to do, but there are more efficient methods of sharing or
updating data than using a mdb as the media.]

-ralph


Chris

unread,
Mar 26, 2009, 7:23:01 AM3/26/09
to
Thanks Ralph ... I will redirect.

Purpose of the mdb file is simple really.

The dump will be of stockcodes,prices etc from our ERP software. Our retail
side is 4 buildings over from our main office (where the server is). The
network is pathetic cause we don't want to spend money - so if a single
switch or network cable connection fails - they have lost the ability to find
prices and use the computers to make a sale!

There are many complications here - an unwillingness to update technology is
one of them :)

By using a front end - and a access db file that gets copied to the 4 tills
on regular intevals - this will help keep the money coming in as I run around
frantically trying to repair the network!

Cheers,
Chris

Ralph

unread,
Mar 26, 2009, 6:17:41 PM3/26/09
to

"Chris" <Ch...@discussions.microsoft.com> wrote in message
news:F9E00CA5-56EF-4D1C...@microsoft.com...

> Thanks Ralph ... I will redirect.
>
> Purpose of the mdb file is simple really.
>
> The dump will be of stockcodes,prices etc from our ERP software. Our
retail
> side is 4 buildings over from our main office (where the server is). The
> network is pathetic cause we don't want to spend money - so if a single
> switch or network cable connection fails - they have lost the ability to
find
> prices and use the computers to make a sale!
>
> There are many complications here - an unwillingness to update technology
is
> one of them :)
>
> By using a front end - and a access db file that gets copied to the 4
tills
> on regular intevals - this will help keep the money coming in as I run
around
> frantically trying to repair the network!
>
> Cheers,
> Chris
>

Makes sense. Didn't say it was wrong, just wanted to make sure you aren't
using it before weighting all options.

Mdb files also have one other advantage. They are viewable, repairable and
editible with simple tools outside your application. (So see, I have nothing
against them at all. lol)

-ralph


0 new messages