I'm new at using a database on a web site. I'm setting up a very simple
database for a client. It has 13,000 records and may grow to 60,000 over
time. It only has four fields per record and people will only be searching
on one field.

So...I set up a test using Access and it works great. The thing is, the
database is 6 megs now and will only get larger. They'll be updating it
steadily using Filemaker Pro and I'll have to convert it and upload it (and
test it, of course).

My question is: In playing around I see a DBF file is tons smaller. It looks
to be about 25% the size. What are the pros and cons to using Access vs.
DBF? If in this simple case DBF will work as well and be a smaller size,
why not go that way?

Any thoughts?

THANKS!

Well, ms-access and all new windows programs use uni-code to store the data.
That means two characters for each single character as compared in older
systems. I would bet that the dbf file is single character.

However, 6 megs in size for 13,000 records sounds a bit high. I have a file
with 20,000 records and it is 5.6 megs. (a bit less then 6 megs).

I assume that 6 megs is after doing a compact and repair on that the file?

I am sure with 25,000 records, you will still be under 10 megs.


--
Albert D. Kallal (MVP)
Edmonton, Alberta Canada
kallal (AT) msn (DOT) com
http://www.attcanada.net/~kallal.msn

"Albert D. Kallal" <kallal (AT) msn (DOT) com> wrote in
newshGUa.526404$3C2.13809170 (AT) news3 (DOT) calgary.shaw.ca:

Really?

--
Lyle

"Lyle Fairfield" wrote

Are you really asking because you want to know, or are you just trolling?

Seems to me that the use of Unicode was one of the benefits you thought made
Access 2000 better than Access 97, so that wouldn't rate a "Really?"

As for "all new Windows programs", I certainly haven't seen them all, and
can't imagine that Albert has, either. I suspect that was a mis-statement
due to Albert being in a hurry to get back to looking at additional new
Windows programs or something.

I'm the original poster. I hate to break up this conversation, but does
anyone have a real answer to my question? I was trying to find out the pros
and cons of using Access vs DBF files for searching on a web site(assuming
I'm only searching one field and not writing to the file), such as speed,
file size, reliability, etc.

THANKS!



"Larry Linson" <larry.linson (AT) ntpcug (DOT) org> wrote

How sad that Albert D. Kallal, who's demonstrated in the past that he's
actually
capable of posting useful answers, has to masquerade as "Larry Linson" and
falsely claim to be an MVP, and, even worse, post a useless reference as
though it were a worthwhile answer.

"Mad Dog" <md (AT) mdp (DOT) com> wrote in
newsPIUa.494$mr1.322 (AT) newsread3 (DOT) news.pas.earthlink.net:

I've considered using a DBF file for what you are suggesting, but have not
done so because I've forgotten too much about DBF files over the years,
and I've not kept up with their changes (I don't know if there have been
any).

The DBF files I remember are very simple. Essentially they are a text file
with a header indicating record and field length.

Indexes are separate files, and in some ways are more powerful than JET
indexes. For instance, one can build conditional indexes: Index on
Surname, FirstName for City = Toronto to TorontoIndex; When one sets the
Index to TorontoIndex one has a small Index to use; in some cases this can
be very fast.

I suppose in trying to sell such an application, I am concerned about
clients who would think a DBF based solution is archaic.

One of the great things about DBF files that I have found over the years
is that a file recovery utility will almost always recover all ones data
even if you lose the file. Corruption seems to be limited to Memo fields;
the pointers for which can get out of whack, but this is infrequent.

--
Lyle

"Larry Linson" <larry.linson (AT) ntpcug (DOT) org> wrote in
news:25IUa.6290$jB5.3271 (AT) nwrddc03 (DOT) gnilink.net:

From the Help File:

"About compressing the data in a Text, Memo, or Hyperlink field
Microsoft Access 2000 or later uses the Unicode character-encoding scheme
to represent the data in a Text, Memo, or Hyperlink field. Unicode
represents each character as two bytes, so the data in a Text, Memo, or
Hyperlink field requires more storage space than it did in Access 97 or
earlier, where each character is represented as one byte.

To offset this effect of Unicode character representation and to ensure
optimal performance, the default value of the Unicode Compression property
for a Text, Memo, or Hyperlink field is Yes. When a field's Unicode
Compression property is set to Yes, any character whose first byte is 0 is
compressed when it is stored and uncompressed when it is retrieved.
Because the first byte of a Latin character — a character of a Western
European language such as English, Spanish, or German — is 0, Unicode
character representation does not affect how much storage space is
required for compressed data that consists entirely of Latin characters.

In a single field, you can store any combination of characters that
Unicode supports. However, if the first byte of a particular character is
not 0, that character is not compressed.

..... "

Really? I posted this more than 3 years ago:

"I've seen many assertions that Access 2000 stores text as unicode. It
does NOT store text data as unicode on my computer (although it does store
object properties as unicode).

"Lyle Fairfield" is stored as the bytes:
4C/79/6C/65/20/46/61/69/72/66/69/65/6C/64
not as
4C/0/79/0/6C/0/65/0/20/0/46/0/61/0/69/0/72/0/66/0/69/0/65/0/6C/0/64/0

What is the basis for the assertion that Access 200[0] stores text as
unicode? It does not seem to be true for characters that do not require
unicode.

I am astounded at the sweeping generalizations about the inadequacies of
Access 2000 that appear here in this newsgroup on a daily basis. Again, I
am asking people who have these problems to publish the databases that
exhibit them, or at least to create small sample databases that show the
problem, zip them up and make them available on a web site or by email.

Uh huh!

--
Lyle

Either one will work fine ... pick whichever you are most comfortable
working with. Of course, if you'd let us know a little more about the
environment (web-based, networked, etc etc) then your choices may be
narrowed. For example, Access/Jet running on a web server can sometimes be
problematic IF there is a lot of traffic performing record additions/edits

But, a 13,000 record file with 4 fields per record at 6 megs does give pause
.... make sure you back up consistently, and perform your compact/repairs
regularly.


"Earthlink" <md (AT) mdp (DOT) com> wrote

It's for a web site and it's very straight forward: four fields, one will be
searched on. Using Access of course I can output it as .mdb or .dbf and use
whichever works best. If indeed one is better than the other.

- I guess what I'm really trying to find out is, if the dbf file is a
smaller (which it is), does that mean it will run faster?

- Does it have the problems you can have with multiple users in Access
(though I don't expect that to be a factor)?

- With all I hear about compacting and repairing Access databases, are dbf
ones less likely to corrupt?

Thanks for the help!


"Scott McDaniel" <junk (AT) junk (DOT) com> wrote