MS Access Reader/Viewer for Windows

[Ewa Wdzieczak-Smering]

Does anyone know of an application that would allow me to
view the mdb files? Or maybe there is something offered by
a third party that would do the trick?

 

[Douglas J. Steele]

Depends on what you mean by "view".

If you want to look at forms or reports, for instance, the answer is no.
There is a royalty-free runtime version of Access, but the application does
need to be "tweaked" a little to ensure that it's compatible with the
run-time.

If all you want is to look at the data, any ODBC-compliant application
should do.

 

[Van T. Dinh]

How would you like to view the mdb files?

The mdb contains lots of objects in a format that only be
decoded by the right versions of Access. Without Access
software to decode, the mdb file is just a big heap of
bits.

If you want to view the data in the Tables, the Tables can
be view as an ODBC datasource or in fact, some
applications like Excel can link to Access Tables.

HTH
Van T. Dinh
MVP (Access)

 

[Guest]

I know I can export the db to something like Excel via the
ODBC... what I was looking for was something like a MS
version of Word viewer, but for Access.
Would the runtime Access be available from MS? So far I
couldn't find it...


Thanks for your help!

 

[Van T. Dinh]

You have to buy the Developer's Version of Office/Access
which has the run-time files. More importantly, ONLY the
Developer's Version licenses you to distribute the run-
time files (with your application) royalty-free.

The Developer's Version is known by variuos name depending
on the Office version. For O2K and OXP, it is known
as "Microsoft Office Developer" or MOD. For 2003, it is
something like "Microsoft Office Visual Studio" or similar.

HTH
Van T. Dinh
MVP (Access)

 

[onedaywhen]

Van T. Dinh MVP (Access) wrote ...

The mdb contains lots of objects in a format that only be
decoded by the right versions of Access. Without Access
software to decode, the mdb file is just a big heap of
bits.

Are you sure about that, did you test? Do the phrases 'Jet' and 'MDAC'
mean anything to you? Just in case you think I'm just being
argumentative:

Standard answer number 2: You don't need the MS Access application to
create and/or query a Jet database (.mdb file). You can do all this on
the fly using only Excel and ADOX (to create the .mdb file; also
create linked tables) and ADO (use DDL statements to create the schema
e.g. CREATE TABLE etc and SQL for queries).

You do need MDAC, free MS download and shipped with Excel, and Jet,
free MS download and shipped with early versions of MDAC, so it's
highly likely you already have the necessary components shipped with
Excel.

See the following links (in these articles, read 'Jet' for the word
'Access'
because the MS Access application is not actually used):

Creating an Access(sic) Database:
http://msdn.microsoft.com/library/d...s/odeopg/html/deovrcreatingaccessdatabase.asp

Running a Temporary Query:
http://msdn.microsoft.com/library/d...s/odeopg/html/deovrcreatingaccessdatabase.asp

Here's some Excel code (run from inside a new blank workbook) which
creates a .mdb, some tables and some sample data, queries the tables
with a join and copies the data to the workbook. You don't need to
uninstall MS Access (unless you remain unconvinced):

Option Explicit

Sub Test()

Dim Cat As Object
Dim Con As Object
Dim rs As Object
Dim strConJet As String
Dim strSql1 As String
Dim strSql2 As String
Dim strSql3 As String
Dim oTarget As Excel.Range
Dim lngCounter As Long

' Amend the following constants to suit
Const FILENAME_JET As String = "" & _
"New_Jet_DB2.mdb"

Const CONN_STRING_JET As String = "" & _
"Provider=Microsoft.Jet.OLEDB.4.0;" & _
"Data Source=<PATH><FILENAME>"

' Build connection string
strConJet = CONN_STRING_JET
strConJet = Replace(strConJet, "<PATH>", _
ThisWorkbook.PATH & Excel.Application.PathSeparator)
strConJet = Replace(strConJet, "<FILENAME>", FILENAME_JET)

' Build sql statements
strSql1 = ""
strSql1 = strSql1 & "CREATE TABLE CommsUsers ("
strSql1 = strSql1 & " ID INTEGER NOT NULL PRIMARY KEY,"
strSql1 = strSql1 & " lname VARCHAR(35) NOT NULL,"
strSql1 = strSql1 & " fname VARCHAR(35) NOT NULL,"
strSql1 = strSql1 & " mname VARCHAR(35) NOT NULL"
strSql1 = strSql1 & " DEFAULT '{{NA}}'"
strSql1 = strSql1 & ");"

strSql2 = ""
strSql2 = strSql2 & "CREATE TABLE Phones ("
strSql2 = strSql2 & " ID INTEGER NOT NULL"
strSql2 = strSql2 & " REFERENCES CommsUsers (ID),"
strSql2 = strSql2 & " Phone VARCHAR(15) NOT NULL"
strSql2 = strSql2 & ");"

strSql3 = ""
strSql3 = strSql3 & "SELECT cm.ID, cm.lname,"
strSql3 = strSql3 & " cm.fname, ph.Phone"
strSql3 = strSql3 & " FROM CommsUsers cm"
strSql3 = strSql3 & " LEFT JOIN Phones ph"
strSql3 = strSql3 & " ON cm.ID=ph.ID;"

' Create new Jet database
Set Cat = CreateObject("ADOX.Catalog")
Cat.CREATE strConJet

' 'inherit' the connection
Set Con = Cat.ActiveConnection
Set Cat = Nothing

With Con

' Create tables
.Execute strSql1
.Execute strSql2

' Create some sample data
.Execute "INSERT INTO CommsUsers (ID, lname, fname)" & _
" VALUES (1, 'Livehulas', 'A')"
.Execute "INSERT INTO CommsUsers (ID, lname, fname)" & _
" VALUES (2, 'Katewudes', 'B')"
.Execute "INSERT INTO CommsUsers (ID, lname, fname)" & _
" VALUES (3, 'Hevitoxic', 'C')"
.Execute "INSERT INTO CommsUsers (ID, lname, fname)" & _
" VALUES (4, 'Norarules', 'D')"
.Execute "INSERT INTO Phones (ID, Phone)" & _
" VALUES (1, '123')"
.Execute "INSERT INTO Phones (ID, Phone)" & _
" VALUES (1, '456')"
.Execute "INSERT INTO Phones (ID, Phone)" & _
" VALUES (2, '555')"
.Execute "INSERT INTO Phones (ID, Phone)" & _
" VALUES (2, '444')"
.Execute "INSERT INTO Phones (ID, Phone)" & _
" VALUES (4, '789')"
End With

' Open recordset
Set rs = Con.Execute(strSql3)

' Copy data to ThisWorkbook
Set oTarget = ThisWorkbook.Worksheets(1) _
.Range("A1")

With rs
For lngCounter = 1 To .fields.Count
oTarget(1, lngCounter).Value = _
.fields(lngCounter - 1).Name
Next
End With

oTarget(2, 1).CopyFromRecordset rs

Con.Close

End Sub

--

 

[Van T. Dinh]

I am sure you read my second paragraph. It is simply one of the many ways
to access data in the JET *Tables*.

The O.P. wrote Access and that includes Access Forms & Reports. Perhaps,
you like to show the O.P. how to access / use the Access Forms and Reports
WITHOUT using Access software???

BTW, you reference to the link:

Creating an Access(sic) Database:

http://msdn.microsoft.com/library/d...s/odeopg/html/deovrcreatingaccessdatabase.asp

creates a JET MDB, not Access MDB if you want to distinguish between Access
and JET and the O.P. wrote "Access", NOT "JET".

Posting code that doesn't help the the original poster doesn't impress
anyone.

Perhaps, you like to answer questions rather than arguing about minor
details ...

 

[Brendan Reynolds]

It is, of course, undeniable that the words 'Access' and 'Jet' are often
used interchangeably, but this is a good example of why that usage, however
common it may be, is wrong. If the question is about how to access (no pun
intended) a Jet database then the answer is, as you say, sure, there are
lots of ways of doing that without Access. If, on the other hand, the
question is about running an Access application, then the answer is no, you
can't do that without Access, either retail or runtime.

Different questions, different answers.

--
Brendan Reynolds (MVP)
http://brenreyn.blogspot.com

The spammers and script-kiddies have succeeded in making it impossible for
me to use a real e-mail address in public newsgroups. E-mail replies to
this post will be deleted without being read. Any e-mail claiming to be
from brenreyn at indigo dot ie that is not digitally signed by me with a
GlobalSign digital certificate is a forgery and should be deleted without
being read. Follow-up questions should in general be posted to the
newsgroup, but if you have a good reason to send me e-mail, you'll find
a useable e-mail address at the URL above.

 

[onedaywhen]

...

It is, of course, undeniable that the words 'Access' and 'Jet' are often
used interchangeably, but this is a good example of why that usage, however
common it may be, is wrong.

Agreed, all too common:

http://groups.google.com/groups?scoring=d&q="Access+is+a+relational+database"

If the question is about how to access (no pun
intended) a Jet database then the answer is, as you say, sure, there are
lots of ways of doing that without Access. If, on the other hand, the
question is about running an Access application, then the answer is no, you
can't do that without Access, either retail or runtime.

Different questions, different answers.

Different interpretations <g>. The question, when I saw it, was 'view
the mdb', later became, 'a viewer for Access'. Viewing the data and
schema is a significant part of a mdb file, so I hope I wasn't being
too irrelevant.

--

 

[peter walker]

Van T. Dinh MVP (Access) wrote ...


Are you sure about that, did you test? Do the phrases 'Jet' and 'MDAC'
mean anything to you? Just in case you think I'm just being
argumentative:

Well if Van isn't sure then I am. Since Van is quite specifically discussing
Access objects in the paragraph, and not generic data tables, then what Van
said is basically true. Whilst the access objects are indeed stored in jet
tables, they are in a proprietry format. Depending on the version of Access
and wether these objects are linked to a VBA projects will determine just
how hard it is to use something other than Access to view them
Jet is merely another ISAM albiet with a SQL execution engine. In this case
the structure of these objects, as oposed to the data definition, is not
imposed by Jet but by Access.

Standard answer number 2: You don't need the MS Access application to
create and/or query a Jet database (.mdb file). You can do all this on
the fly using only Excel and ADOX (to create the .mdb file; also
create linked tables) and ADO (use DDL statements to create the schema
e.g. CREATE TABLE etc and SQL for queries).

One would assume that if the poster wants a simple reader, he is propably
not up to useing your convoluted and superfluous code. Since we are dealing
with Jet I would have thought DAO would have been a better choice over ADO
in any case. Perhaps that is why it is standard answer number 2 (as opposed
to 1)

You do need MDAC, free MS download and shipped with Excel, and Jet,
free MS download and shipped with early versions of MDAC, so it's
highly likely you already have the necessary components shipped with
Excel.

[] Irrelevant code snipped

peter walker mvp nnsa

 

[onedaywhen]

...

your convoluted and superfluous ... irrelevant code

I genuinely appreciate constructive feedback, particularly negative
(the other kind makes me blush). However, for the second time in the
same thread, I find myself asking of someone who should know better:
can you please give me some details on where and how my code could be
improved? For example, convoluted where, how would you make that part
less convoluted? Bear in mind the code is meant to be demo and thus
contains essentially superfluous code; I can think of no real life
situation where I'd create a new database with two new populated
tables simply for the sake of querying them.

Since we are dealing
with Jet I would have thought DAO would have been
a better choice over ADO

Hasn't the 'DAO or ADO?' debate been played out enough in these ngs?
We could do it again but instead here's a consensus position: DAO and
ADO are equally valid and the choice is merely a 'lifestyle' one, so
don't be down on someone for not using your personal preference. My
apps need to additionally work with SQL Server and Oracle (among other
DBMSs) and in my experience Oracle reacts very badly to DAO so my
lifestyle choice is already made. So, no, my Standard Answer Number 1
does not use DAO code.

Jet is merely another ISAM albiet
with a SQL execution engine.

In one sentence you have restored my faith in MS Access MVPs! I'd be
interested in your take on the following:

http://groups.google.com/groups?scoring=d&q="Access+is+a+relational+database"

Do you think as a minimum requirement MS Access MVPs should know what
Jet is? What would be best way of getting the message out there? The
only way I can think of would likely end up with me being bumped off
by the MS Access MVP contingent. What's the MS Access equivalent of
'Swims with the fishes'? 'Dropped without constraint'?

--

 

[peter walker]

...


I genuinely appreciate constructive feedback, particularly negative
(the other kind makes me blush). However, for the second time in the
same thread, I find myself asking of someone who should know better:
can you please give me some details on where and how my code could be
improved? For example, convoluted where, how would you make that part
less convoluted? Bear in mind the code is meant to be demo and thus
contains essentially superfluous code; I can think of no real life
situation where I'd create a new database with two new populated
tables simply for the sake of querying them.

The OP didn't want to know how to create or deleted records or learn ado or
dao or any of that. He just wanted a simple viewer.

Hasn't the 'DAO or ADO?' debate been played out enough in these ngs?
We could do it again but instead here's a consensus position: DAO and
ADO are equally valid and the choice is merely a 'lifestyle' one, so
don't be down on someone for not using your personal preference. My
apps need to additionally work with SQL Server and Oracle (among other
DBMSs) and in my experience Oracle reacts very badly to DAO so my
lifestyle choice is already made. So, no, my Standard Answer Number 1
does not use DAO code.

Dao was specifically is geared and optimized for JET. Any other usefulness
has been appended over time. The core code remains basically unchanged. ADO
was developerd because of the shortcommings of ths Jet bias in the DAO
architecture.

In one sentence you have restored my faith in MS Access MVPs! I'd be
interested in your take on the following:

http://groups.google.com/groups?scoring=d&q="Access+is+a+relational+database"

MS classifies Access as a Relational Database Management System - RDBMS. It
is not a Relational Database That would be the end result. But other than
that I'm not sure what your point is?

Do you think as a minimum requirement MS Access MVPs should know what
Jet is? What would be best way of getting the message out there? The
only way I can think of would likely end up with me being bumped off
by the MS Access MVP contingent. What's the MS Access equivalent of
'Swims with the fishes'? 'Dropped without constraint'?

Not sure what you're talking about here either. I know what Jet is (since
1993) and prior to that I used BTrieve and prior to that I used my own ISAM.
Van knows what Jet isalso.

Not sure what point you are trying to prove here.
--

peter walker MVP

Please post replies to the news group so everyone can benefit.
www.papwalker.com

 

[onedaywhen]

...

Dao was <snip>

If that's a line, I ain't biting.

I'm not sure what your point is?
Not sure what point you are trying to prove here.

Sorry, I'm being subtle again. Allow me to be blunt:

Van T. Dinh MS Access MVP said

"Without Access software to decode, the
mdb file is just a big heap of bits."

This is verifiably incorrect as my earlier code demonstrates. Sure,
the context was MS Access objects, but the statement is unqualified
and my challenge is justified.

John W. Vinson MS Access MVP says (*regularly* in these ngs):

"Access is a relational database."

(http://groups.google.com/groups?q="...se"+author:jvinson@STOP_SPAM.WysardOfInfo.com)

I think this is wrong. peter walker MS Access MVP says

MS classifies Access as a Relational Database Management System - RDBMS. It
is not a Relational Database

I think this is correct, noting you have not endorsed MS's
classification. I would appreciate it if you could suggest to John W.
Vinson MS Access MVP some suitable wording to correct his Standard
Answer.

I think I'm now fish food.

--