is there any other alternative to memo fields

M

MoinJ

Sorry, I can't handle a 30MB download. If you want to take the time to
make a copy of the database, delete almost all the records, compact it
and zip it so that it's 1MB or smaller in size, then you may send it to
me.
Click to expand...

Ok, i have deleted all records except 10 and after compacting it i have sent
you the zipped mdb file at [email protected]. Please add around 500k to
600k records and let me know.

Thanks.
 
D

Dirk Goldgar

MoinJ said:
Ok, i have deleted all records except 10 and after compacting it i
have sent you the zipped mdb file at <deleted>. Please add
around 500k to 600k records and let me know.
Click to expand...

Blast it, Moin! I go to great lengths not to post my e-mail address in
a public forum, and then you go and do it. That is EXTREMELY bad
manners, and likely to cause me considerable annoyance. Don't you know
that spammers and viruses both harvest addresses from newsgroups? Never
do that again! And please attempt to cancel your post immediately.
 
D

Dirk Goldgar

MoinJ said:
Ok, i have deleted all records except 10 and after compacting it i
have sent you the zipped mdb file at [email protected]. Please add
around 500k to 600k records and let me know.
Click to expand...

No need. You remember where I asked:
Are you sure the field [level_2] is indexed? Is it a numeric
field?
Click to expand...
Click to expand...

And you replied:
Yes, it is indexed and is a numeric field.
Click to expand...

I just looked at your table design and the [LEVEL_2] field is *not*
indexed. That means that any query, such as the one you posted, that
uses that field in a WHERE clause is going to have to do a full table
scan, and therein lies the reason for your query's slowness. The
solution is to index that field.

I see that you have fields named LEVEL_1_INDEX and LEVEL_2_INDEX. These
fields are not indexed either, but they make me wonder whether you
intended those to be indexes. It doesn't work that way.
 
D

Dirk Goldgar

MoinJ said:
Ok, i have deleted all records except 10 and after compacting it i
have sent you the zipped mdb file at <deleted>. Please add
around 500k to 600k records and let me know.
Click to expand...

No need. You remember where I asked:
Are you sure the field [level_2] is indexed? Is it a numeric
field?
Click to expand...
Click to expand...

And you replied:
Yes, it is indexed and is a numeric field.
Click to expand...

I just looked at your table design and the [LEVEL_2] field is *not*
indexed. That means that any query, such as the one you posted, that
uses that field in a WHERE clause is going to have to do a full table
scan, and therein lies the reason for your query's slowness. The
solution is to index that field.

I see that you have fields named LEVEL_1_INDEX and LEVEL_2_INDEX. These
fields are not indexed either, but they make me wonder whether you
intended those to be indexes. It doesn't work that way.
 
M

MoinJ

Yeah, i read it late last night, but only got to it a couple hours ago.
Those indexes were overlooked by me. I had the columns correctly indexed at
first, but I played around too much with the MDB and had several copies of
MDB's with me, leading to the final MDB not having the correct indexes. As
for the LEVEL_1_INDEX and LEVEL_2_INDEX fields, those fields are unrelated to
my current problem.

I really appreciate your way of quick responses. You are being very helpful.
I would need some more help from you.

Thanks again,
Moin.
 
Top