--- In [email protected], "Shawn K. Hall" <[EMAIL PROTECTED]> wrote:
> Hi Chris,
>
> > Mainly I just would like to know why this stuff is
> > happening.
>
> It could be a field type or scope problem, or could be related to
> the type of query you're opening. For example, if you're pulling
> data from two tables with the same field name in each and trying to
> bind it only as [fieldname], even though the data is supposed to be
> the exact same on both, it really is different fields and needs to
> be bound differently.
I am just trying to open up the DB in VisData. I can see the
structure, but when I try to actually look at the data I get the
error.
> Unless of course, you're seriously using tables with 70 and 145
> fields. Whatever possessed you?
As a matter of fact, that's exactly what I am doing. I create a
database with one table. The table has fields that correspond to the
fields on the document, which can be anywhere from 2 to, the most
recent job, 145 fields. There are also a few more fields that have
user name, date, record number, and other misc info, so you're
looking at about 150 fields. I use the Access DB because of its
proven stability, and because it's all I've used in the last year.
One file contains one batch worth of documents. I then convert these
batches (DB files) to the customers requested data format. I then
have an edit program process that data to check for any missed errors
and final check on the data before the customer gets it.
If it would help, I guess I could have a table for each page of
the document, with each table sharing a record number identifier, so
it would be 8 tables with under 20 fields per table, per record
number. Would something like this be a better approach? It just
seemed logical to me to have it all together in one table.
> Before you consider stuffing all the data you have on any resource
> into the same table you should really try to see if it *needs* to be
> all bound to the same table. Usually stuffing all that data into the
> same table, aside from being a memory waste and space hog in access,
> results in severely limiting what you can do with it. For example,
For different project types I can see what you mean. But, what
if you are processing 5000 chuck mc donalds birthday club
applications, divided into 10 batches of 500 each. For the example
we'll say there's actually 150 fields worth of data on each
application. How can I more effectively design a DB that the data
entry operators store this entered data into? Once these database
files are processed they are not used again. The operators are not
all together on a network or anything they're using separate machines
in separate locations and then email the individual database batch
files to me for processing. The scope of the projects require I have
separate files for each batch. Again, the reason I don't store the
data in another format is for the proven stability of the access
databases, although each individual file at a minimum is just large
enough not to fit on a floppy. If their power goes out their data is
pretty much still intact though.
Someday I would like to use ASP and just have them enter it
online, but that is far in the future. I have too many other
upcoming projects, and always looming time constraints... I am lucky
if I get a full day for some projects. Bigger projects usually two
days. I wish I could write every program from the ground up, but by
the time I get home I am lucky enough to have enough energy to watch
Blue's Clues with my son before I go to sleep on the couch. I didn't
even get this whole message finished before he came in here and
hopped in my lap. This type of thing makes it hard to work at home
without sacrificing my time with him, and it's just he and I here.
Blah blah...
[C]
'// =======================================================
Rules : http://ReliableAnswers.com/List/Rules.asp
Home : http://groups.yahoo.com/group/vbHelp/
=======================================================
Post : [email protected]
Join : [EMAIL PROTECTED]
Leave : [EMAIL PROTECTED]
'// =======================================================
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/vbhelp/
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
