Using an MS Access DB as the data storage 
Author Message
 Using an MS Access DB as the data storage

Hi All

Looking to make a football manager game whereby I need to store a lot of
stats in a form of DB.

I use ASP/ADO/Access on a daily basis, so I thought I would make the game in
a VB to Access DB combo.  Does anybody know any problems with doing this
combo?

I want to make the game freeware, but what if the user doesn't have MS
Access?  Can the DB still interface with my VB app?

If there has to be some form of run-time does it make the whole installer
monstrously oversized, eg VB app (nice and small), MS Access DB run-time
files (HUGE!!!) and ADO 'glue' (HUGE!!!)?

Any help you can suggest on how I should store my data and what the pitfalls
can be before I start would be very much appreciated.

Rgds

Laphan

http://www.*-*-*.com/



Tue, 06 Dec 2005 04:16:36 GMT  
 Using an MS Access DB as the data storage
There are no problems using VB with an MS Access database, and the user does
not need Access in order for the application to work.  You do need to
distribute MDAC (ADO "glue") and MS Jet (the Access DB run-time engine).
Assuming you use ADO 2.6 or newer, the Jet engine is distributed separately
from the Jet engine.  Both are available for download from
www.microsoft.com/data, and they are both several Mb.

MS Access will work fine for a handful of users and tens (or maybe even a
few hundreds) of thousands of rows (in each table).  There are examples of
applications working well for several hundred users with a significant
amount of data working OK.  But if you have considerably more data (mid to
upper six figures or more) and multiple users, you may find that moving to
MSDE (limited number of users or paralell sessions, but good for a sizable
amount of data) and/or MySQL may give you better results.

You can separate the downloads:  One for your app (and its non-db
prerequisites), and separate downloads for MDAC and Jet (link to the MS
site).  Some also have downloads with and without the VB runtime included.

If the MS Access database will be used as a multiuser database, it is
advisable to split it into two:  A "shared data" database, containing the
tables and data that is shared between all the users, and a "private"
database that contains any QueryDefs, temporary/scratch/working tables, and
links to the shared data tables.  Your install program would have two
options, one for installing the shared database, and one for installing the
application including the "private" database.

This split reduces the number of database corruption issues you will
encounter, and allows you to implement a sort of "temporary" tables.  While
the tables aren't temporary, you can create and delete (or truncate) them on
the fly in the private database without affecting any other users.

HTH,
Tore.


Quote:
> Hi All

> Looking to make a football manager game whereby I need to store a lot of
> stats in a form of DB.

> I use ASP/ADO/Access on a daily basis, so I thought I would make the game
in
> a VB to Access DB combo.  Does anybody know any problems with doing this
> combo?

> I want to make the game freeware, but what if the user doesn't have MS
> Access?  Can the DB still interface with my VB app?

> If there has to be some form of run-time does it make the whole installer
> monstrously oversized, eg VB app (nice and small), MS Access DB run-time
> files (HUGE!!!) and ADO 'glue' (HUGE!!!)?

> Any help you can suggest on how I should store my data and what the
pitfalls
> can be before I start would be very much appreciated.

> Rgds

> Laphan

> http://www.frozenmoles.co.uk



Tue, 06 Dec 2005 12:30:03 GMT  
 Using an MS Access DB as the data storage
In my old job I had an Access DB with over 1 million rows,
it was quite a wide table aswell and added to every day.
It produced reports of timekeeping information for staff
and has probably now got about 1.5 million, the
information was gained from a HORRIBLE oracle database,
the main table of which gained 100,000 rows per day and
was purged every so many days or whenever it felt like it.
The network was so poor that a connection to it wasn't
possible, the data could only be retrieved by downloading
text files and importing them.
(also see inline..->)

Quote:
>-----Original Message-----
>There are no problems using VB with an MS Access

database, and the user does
Quote:
>not need Access in order for the application to work.  
You do need to
>distribute MDAC (ADO "glue") and MS Jet (the Access DB
run-time engine).
>Assuming you use ADO 2.6 or newer, the Jet engine is

distributed separately

Quote:
>from the Jet engine.  

The jet engine is distributed separately from the jet
engine? eh?!

Both are available for download from

Quote:
>www.microsoft.com/data, and they are both several Mb.

>MS Access will work fine for a handful of users and tens
(or maybe even a
>few hundreds) of thousands of rows (in each table).  

There are examples of
Quote:
>applications working well for several hundred users with
a significant
>amount of data working OK.  But if you have considerably
more data (mid to
>upper six figures or more) and multiple users, you may
find that moving to
>MSDE (limited number of users or paralell sessions, but
good for a sizable
>amount of data) and/or MySQL may give you better results.

>You can separate the downloads:  One for your app (and
its non-db
>prerequisites), and separate downloads for MDAC and Jet
(link to the MS
>site).  Some also have downloads with and without the VB
runtime included.

>If the MS Access database will be used as a multiuser
database, it is
>advisable to split it into two:  A "shared data"

database, containing the
Quote:
>tables and data that is shared between all the users, and
a "private"
>database that contains any QueryDefs,

temporary/scratch/working tables, and
Quote:
>links to the shared data tables.  Your install program
would have two
>options, one for installing the shared database, and one
for installing the
>application including the "private" database.

>This split reduces the number of database corruption
issues you will
>encounter, and allows you to implement a sort

of "temporary" tables.  While
Quote:
>the tables aren't temporary, you can create and delete

(or truncate) them on

- Show quoted text -

Quote:
>the fly in the private database without affecting any
other users.

>HTH,
>Tore.



>> Hi All

>> Looking to make a football manager game whereby I need
to store a lot of
>> stats in a form of DB.

>> I use ASP/ADO/Access on a daily basis, so I thought I
would make the game
>in
>> a VB to Access DB combo.  Does anybody know any

problems with doing this

- Show quoted text -

Quote:
>> combo?

>> I want to make the game freeware, but what if the user
doesn't have MS
>> Access?  Can the DB still interface with my VB app?

>> If there has to be some form of run-time does it make
the whole installer
>> monstrously oversized, eg VB app (nice and small), MS
Access DB run-time
>> files (HUGE!!!) and ADO 'glue' (HUGE!!!)?

>> Any help you can suggest on how I should store my data
and what the
>pitfalls
>> can be before I start would be very much appreciated.

>> Rgds

>> Laphan

>> http://www.frozenmoles.co.uk

>.



Tue, 06 Dec 2005 16:28:53 GMT  
 Using an MS Access DB as the data storage
I can't believe how beefy this setup would make my program.

I wanted to allow users to download it from my web site once I'd created it,
but at this rate they may need a T1 connection to do it!!!!

5MB for ADO and 4MB for the Access Run-time.  My app will be 10MB before I
even create anything!!

What do people use for a back-end data storage that they need to write to
and query??

I can't be the first to do this sort of thing - surely??

Rgds

Laphan


In my old job I had an Access DB with over 1 million rows,
it was quite a wide table aswell and added to every day.
It produced reports of timekeeping information for staff
and has probably now got about 1.5 million, the
information was gained from a HORRIBLE oracle database,
the main table of which gained 100,000 rows per day and
was purged every so many days or whenever it felt like it.
The network was so poor that a connection to it wasn't
possible, the data could only be retrieved by downloading
text files and importing them.
(also see inline..->)

Quote:
>-----Original Message-----
>There are no problems using VB with an MS Access

database, and the user does
Quote:
>not need Access in order for the application to work.
You do need to
>distribute MDAC (ADO "glue") and MS Jet (the Access DB
run-time engine).
>Assuming you use ADO 2.6 or newer, the Jet engine is

distributed separately

Quote:
>from the Jet engine.

The jet engine is distributed separately from the jet
engine? eh?!

Both are available for download from

Quote:
>www.microsoft.com/data, and they are both several Mb.

>MS Access will work fine for a handful of users and tens
(or maybe even a
>few hundreds) of thousands of rows (in each table).

There are examples of
Quote:
>applications working well for several hundred users with
a significant
>amount of data working OK.  But if you have considerably
more data (mid to
>upper six figures or more) and multiple users, you may
find that moving to
>MSDE (limited number of users or paralell sessions, but
good for a sizable
>amount of data) and/or MySQL may give you better results.

>You can separate the downloads:  One for your app (and
its non-db
>prerequisites), and separate downloads for MDAC and Jet
(link to the MS
>site).  Some also have downloads with and without the VB
runtime included.

>If the MS Access database will be used as a multiuser
database, it is
>advisable to split it into two:  A "shared data"

database, containing the
Quote:
>tables and data that is shared between all the users, and
a "private"
>database that contains any QueryDefs,

temporary/scratch/working tables, and
Quote:
>links to the shared data tables.  Your install program
would have two
>options, one for installing the shared database, and one
for installing the
>application including the "private" database.

>This split reduces the number of database corruption
issues you will
>encounter, and allows you to implement a sort

of "temporary" tables.  While
Quote:
>the tables aren't temporary, you can create and delete

(or truncate) them on

- Show quoted text -

Quote:
>the fly in the private database without affecting any
other users.

>HTH,
>Tore.



>> Hi All

>> Looking to make a football manager game whereby I need
to store a lot of
>> stats in a form of DB.

>> I use ASP/ADO/Access on a daily basis, so I thought I
would make the game
>in
>> a VB to Access DB combo.  Does anybody know any

problems with doing this

- Show quoted text -

Quote:
>> combo?

>> I want to make the game freeware, but what if the user
doesn't have MS
>> Access?  Can the DB still interface with my VB app?

>> If there has to be some form of run-time does it make
the whole installer
>> monstrously oversized, eg VB app (nice and small), MS
Access DB run-time
>> files (HUGE!!!) and ADO 'glue' (HUGE!!!)?

>> Any help you can suggest on how I should store my data
and what the
>pitfalls
>> can be before I start would be very much appreciated.

>> Rgds

>> Laphan

>> http://www.frozenmoles.co.uk

>.



Wed, 07 Dec 2005 02:50:33 GMT  
 
 [ 4 post ] 

 Relevant Pages 

1. Using an MS Access DB as the data storage

2. Using MS Data Shaping with OLE DB - data from more than one table in mpp file

3. Help, using an Access 97 DB without MS Access Application

4. Help, using an Access 97 DB without MS Access Application

5. Help, using an Access 97 DB without MS Access Application

6. export data from one access db to same db on another machine using vb6

7. Using a Data Control in VB5 accessing a user-level secure Access 97 DB

8. How to use MS Jet to access data fr Access2000 db

9. data transfer from word form to ms access db

10. Any problems converting Ms ACCESS db data to ORACLE 7

11. How to use MS Jet to access data fr Access2000 db

12. How to use MS Jet to access data fr Access2000 db

 

 
Powered by phpBB® Forum Software