Different no of records

[Ray]

I have a input form linked to a table and found the total no of records on
the bottom bar is different from that of table. Can someone advise an
effective way to find out the different records since there are over 20k
records.

Thanks,

Ray

[Trevor Best]

Ray wrote:

I have a input form linked to a table and found the total no of records on
the bottom bar is different from that of table. Can someone advise an
effective way to find out the different records since there are over 20k
records.

Go to the last record, any difference?

Look at the recordsource, it it the table or a query?
Look at the Filter property of the form.

--
This sig left intentionally blank

[Ray]

Trevor,

Thanks for your hints.

The record source is a query, not a direct table. It requires the match
with the product code of the product table. Obviously, the user may enter
some data into the table direct without using the input form. How can I
filter out the matching records leaving unmatched records?

Thanks,

Ray

"Trevor Best" <no****@besty.org.uk> wrote in message
news:41**********************@news.zen.co.uk...

Ray wrote:

I have a input form linked to a table and found the total no of records
on the bottom bar is different from that of table. Can someone advise an
effective way to find out the different records since there are over 20k
records.

Go to the last record, any difference?

Look at the recordsource, it it the table or a query?
Look at the Filter property of the form.

--
This sig left intentionally blank

[Trevor Best]

Ray wrote:

Trevor,

Thanks for your hints.

The record source is a query, not a direct table. It requires the match
with the product code of the product table. Obviously, the user may enter
some data into the table direct without using the input form. How can I
filter out the matching records leaving unmatched records?

Not sure what you're getting at here, will the "Find Unmatched" query
wizard help?

--
This sig left intentionally blank

[NeilAnderson]

Ray

Never, ever, ever, ever let users enter data directly into a table -
don't even do it yourself. You've already found out one of the reasons
that it is not a good idea.

Matching records: use a self join query to get duplicates something
like:-

"SELECT * FROM atable as a INNER JOIN atable as b ON a.somefield =
b.somefield
WHERE a.notherfield = b.notherfield" etc etc You can use the query
design grid to do this. Then delete the extras, by hand so that you
never allow people access to your tables again ;-)

Neil
"Ray" <No**************@Yahoo.com.hk> wrote in message news:<30*************@uni-berlin.de>...

Trevor,

Thanks for your hints.

The record source is a query, not a direct table. It requires the match
with the product code of the product table. Obviously, the user may enter
some data into the table direct without using the input form. How can I
filter out the matching records leaving unmatched records?

Thanks,

Ray

"Trevor Best" <no****@besty.org.uk> wrote in message
news:41**********************@news.zen.co.uk...

Ray wrote:

I have a input form linked to a table and found the total no of records
on the bottom bar is different from that of table. Can someone advise an
effective way to find out the different records since there are over 20k
records.

Go to the last record, any difference?

Look at the recordsource, it it the table or a query?
Look at the Filter property of the form.

--
This sig left intentionally blank

[Ray]

Neil,

Many thanks for your good advice.

I need your further advice how to prohibit other users to enter the data
from the table. If there is only one user, it may be easier. Now, the
database is accessed by a number of users and they need to develop their own
tables/shared tables, queries and reports to fit their needs.

Thanks,

Ray

"NeilAnderson" <ne***********@boroughmuir.edin.sch.uk> wrote in message
news:83**************************@posting.google.c om...

Ray

Never, ever, ever, ever let users enter data directly into a table -
don't even do it yourself. You've already found out one of the reasons
that it is not a good idea.

Matching records: use a self join query to get duplicates something
like:-

"SELECT * FROM atable as a INNER JOIN atable as b ON a.somefield =
b.somefield
WHERE a.notherfield = b.notherfield" etc etc You can use the query
design grid to do this. Then delete the extras, by hand so that you
never allow people access to your tables again ;-)

Neil
"Ray" <No**************@Yahoo.com.hk> wrote in message
news:<30*************@uni-berlin.de>...

Trevor,

Thanks for your hints.

The record source is a query, not a direct table. It requires the match
with the product code of the product table. Obviously, the user may
enter
some data into the table direct without using the input form. How can I
filter out the matching records leaving unmatched records?

Thanks,

Ray

"Trevor Best" <no****@besty.org.uk> wrote in message
news:41**********************@news.zen.co.uk...

> Ray wrote:
>> I have a input form linked to a table and found the total no of
>> records
>> on the bottom bar is different from that of table. Can someone advise
>> an
>> effective way to find out the different records since there are over
>> 20k
>> records.
>
> Go to the last record, any difference?
>
> Look at the recordsource, it it the table or a query?
> Look at the Filter property of the form.
>
> --
> This sig left intentionally blank

[Ray]

Trevor,

Find Unmatched" query wizard is useful solution.

Thank,

Ray

"Trevor Best" <no****@besty.org.uk> wrote in message
news:41**********************@news.zen.co.uk...

Ray wrote:

Trevor,

Thanks for your hints.

The record source is a query, not a direct table. It requires the match
with the product code of the product table. Obviously, the user may
enter some data into the table direct without using the input form. How
can I filter out the matching records leaving unmatched records?

Not sure what you're getting at here, will the "Find Unmatched" query
wizard help?

--
This sig left intentionally blank

[NeilAnderson]

Ray

Do they really need to develop their own tables? If they do then you
probably haven't got the design right. Changing the structure of a
database on the fly is just plain dangerous. I can't think of ANY case
where it might be neccesary.

As to the queries, I can see the point here, but you can quite easily
design
a form to give the user the functionality of a select query without
letting them actually create one. For SELECT queries that is. All the
action queries should be designed by you. I don't know if you've ever
had the "pleasure" of running a slightly off DELETE or UPDATE query,
you really should try it once!!
Then think about what someone might do to your 20k worth of records!!

I've never had to let user design reports but I do know that it can be
done, search in this group.

As to what your users can see and do, all mine get a mde front end,
possibly with the shift key disabled, so that they can never meddle
where they are not wanted.

HTH

Neil

"Ray" <No**************@Yahoo.com.HK> wrote in message news:<31*************@uni-berlin.de>...

Neil,

Many thanks for your good advice.

I need your further advice how to prohibit other users to enter the data
from the table. If there is only one user, it may be easier. Now, the
database is accessed by a number of users and they need to develop their own
tables/shared tables, queries and reports to fit their needs.

Thanks,

Ray

"NeilAnderson" <ne***********@boroughmuir.edin.sch.uk> wrote in message
news:83**************************@posting.google.c om...

Ray

Never, ever, ever, ever let users enter data directly into a table -
don't even do it yourself. You've already found out one of the reasons
that it is not a good idea.

Matching records: use a self join query to get duplicates something
like:-

"SELECT * FROM atable as a INNER JOIN atable as b ON a.somefield =
b.somefield
WHERE a.notherfield = b.notherfield" etc etc You can use the query
design grid to do this. Then delete the extras, by hand so that you
never allow people access to your tables again ;-)

Neil
"Ray" <No**************@Yahoo.com.hk> wrote in message
news:<30*************@uni-berlin.de>...

Trevor,

Thanks for your hints.

The record source is a query, not a direct table. It requires the match
with the product code of the product table. Obviously, the user may
enter
some data into the table direct without using the input form. How can I
filter out the matching records leaving unmatched records?

Thanks,

Ray

"Trevor Best" <no****@besty.org.uk> wrote in message
news:41**********************@news.zen.co.uk...
> Ray wrote:
>> I have a input form linked to a table and found the total no of
>> records
>> on the bottom bar is different from that of table. Can someone advise
>> an
>> effective way to find out the different records since there are over
>> 20k
>> records.
>
> Go to the last record, any difference?
>
> Look at the recordsource, it it the table or a query?
> Look at the Filter property of the form.
>
> --
> This sig left intentionally blank