Posted by Jim Carlock on 02/11/06 09:21

"Jim Carlock" <anonymous@127.0.0.1> wrote:
>Or, could the file be placed upon a Unix machine, then connected to
>via a network connection (network share) from a Windows machine?

"Tim Roberts" <timr@probo.com> replied:
> Do you mean something like Samba? That will work, but there are
> two issues. First, Access is not very smart about the way it reads
> the database file, and most Access programmers are even worse.

Well, I'm thinking along the lines of Access connecting to Access,
and Access connecting to other. I'm lacking in experience in
connecting from other to Access. There are two ways I can think
of whereby Access can connect to other...

(1) The database being connected to is recognized,
(2) The database is unrecognized, in which case some sort of
ODBC or SQL serving connection must be used. So a third
party connector existed and Access hooked up to it okay. I
was thinking about going in the reverse direction though,
whereby perhaps some third party tool already exists that
can connect to an Access data file and thereby send Access
SQL statements to it.

> Talking to an Access database over a network share can be a
> painful exercise in patience.

Well, perhaps, but only if you insist. :-) The ADO methods seem
alot slower than the DAO methods. I won't say that I'm familiar
with accessing Access in anything but a Microsoft environment
though.

> <soapbox>
> Access is a flexible, powerful, and easy to use program, but
> in my view, one of the most serious shortcomings in all 11
> versions of Access has been the complete lack of a simple
> "export to SQL" command.
> </soapbox>

Access provides a visual way to create queries. Right clicking inside
the query created then offers a drop down menu whereby you can
select SQL View to get the "Access SQL" version of the query. I've
used this in the past to pop an SQL query into a external application,
use links to external data on "other servers" to create tables inside
Access. Of course every dialect of SQL differs somewhat.

Furthermore, SQL is just a scripting language for collecting a group
of data. The presentation of the data gets handled outside of SQL.
SQL doesn't provide the file format, it's just a scripting language,
and when dealing with databases, I tend to think along the lines of
recordsets and queries and SQL provides the syntax for acquiring
the recordset (or creating or editing a recordset).

> When I take a backup of a database, I would much rather have a
> file that I can read (and manipulate) than a copy of an opaque binary
> file.

Okay, I think I see what you're saying, that going along the lines
of ISAM files. An Access "link" provides a way to connect to external
data file types. Once "linked", the normal gambit of "SQL" operations
could commence. Microsoft provides some limited ways to "link" to
some well know data types (ie, text files/csv, txt, asc, tab, Access
mdb/mde/mda, dbase III/dbf, dbase V/dbf, dbase IV/dbf, paradox/db,
html/htm, and a couple Microsoft types/Outlook+Exchange).

A third party ODBC connection might be of use.

> By the way, here are a couple of web pages that describe how
> to move from Access and SQL Server to MySQL:
>
> http://dev.mysql.com/tech-resources/articles/migrating-from-microsoft.html
> http://www.kitebird.com/articles/access-migrate.html

Thanks for the links, Tim. I think my original thoughts fell along
the lines of linking to an Access .mdb and then extracting the
data from such. I lack experience in moving data out of Access
to another format though. I kind of hoped that there was an
easy way to connect to an Access .mdb and still am not sure
that an easy way exists from a non-Microsoft client. IIS and
other scripting languages provides ways to easily extract data
from an Access .mdb and present it in an XML format...

Just throwing some thoughts out.

Jim Carlock
Post replies to the group.

[Back to original message]