Autonumber doesn't start at 1

Tina's provided a mechanism for you to do what you asked about.

And my question is still "why?" Why does it matter what value an autonumber
field holds?

The Access Autonumber is intended for use as a unique identifier. Using it
to denote sequence, or a user-viewable value is asking for issues later on,
and is a little like using a screwdriver to pound in nails -- you can do it,
but:
it wasn't intended for that use,
it's harder than using the right tool, and
you can hurt yourself

--
Good luck

Jeff Boyce
Access MVP

I understand and agree completely with everything you say. My only concern
is from my developer's standpoint, I use the field in WHERE conditions like
"ReportID IN (12345, 12346, 12347, 12377, 23466, 43566, 23434, 54545, 56565,
.... etc)" that may have up to a hundred records (hand-picked by the user in
a multi-select listbox). I'm not sure if there's a maximum string length to
that WHERE condition string, but double- and triple-digit numbers keep it
shorter than 4- and 5-digit ones.

Also, as I develop this app, it makes it much easier for me to debug when I
can see the ReportIDs in the string, and I can recognize if they are coming
out of a particular set of records that are related by a Foreign Key field.
When I de-populate and re-populate the tables, I like to recognize the
patterns the same way I've seen them before.

To answer your question: I have no plans to reset the autonumber once the
application is developed/deployed.

Thanks for your insights. If you know about a maximum string size for the
WhereCondition (or maximum for an ordinary SQL statement), I am curious to
know it.

Thank you.

Paul Johnson

"Jeff Boyce" -DISCARD_HYPHEN_TO_END wrote in message
...
Tina's provided a mechanism for you to do what you asked about.

And my question is still "why?" Why does it matter what value an
autonumber
field holds?

The Access Autonumber is intended for use as a unique identifier. Using
it
to denote sequence, or a user-viewable value is asking for issues later
on,
and is a little like using a screwdriver to pound in nails -- you can do
it,
but:
it wasn't intended for that use,
it's harder than using the right tool, and
you can hurt yourself

--
Good luck

Jeff Boyce
Access MVP

Paul

(see in-line comments)

I understand and agree completely with everything you say. My only
concern
is from my developer's standpoint, I use the field in WHERE conditions
like
"ReportID IN (12345, 12346, 12347, 12377, 23466, 43566, 23434, 54545,
56565,
... etc)" that may have up to a hundred records (hand-picked by the user
in
a multi-select listbox). I'm not sure if there's a maximum string length
to
that WHERE condition string, but double- and triple-digit numbers keep it
shorter than 4- and 5-digit ones.

I believe there is a maximum string length for a SQL statement, so I can see
how saving 1 (or 3) digits could help with your approach. I'm wondering
(speculation only) if another approach could eliminate the need for that
portion of the string altogether... My thoughts (untested) are slanted
toward the use of a temporary table that holds the (multi-)selected listbox
row IDs. Then it seems you could use a join to that temp table (list) of
IDs. Just a thought...


Also, as I develop this app, it makes it much easier for me to debug when
I
can see the ReportIDs in the string, and I can recognize if they are
coming
out of a particular set of records that are related by a Foreign Key
field.
When I de-populate and re-populate the tables, I like to recognize the
patterns the same way I've seen them before.


I can see this, working "behind the curtain" myself. So the "business need"
I asked about is YOUR business need!

To answer your question: I have no plans to reset the autonumber once the
application is developed/deployed.

Thanks for your insights. If you know about a maximum string size for the
WhereCondition (or maximum for an ordinary SQL statement), I am curious to
know it.

Thank you.

Paul Johnson

JOPO (just one person's opinions)

Jeff Boyce
Access MVP

Jeff,

That's a great idea. I may try pushing the limits of the present system, by
populating the table into 5-digit ID nos and selecting more than my typical
user is ever expected to select, just to see if I exceed the capacity of the
Where condition string. If I can't break it, I'll leave it alone, but if I
can crash it, I'll use a table. It makes more sense to let the numerous
records be identified in the USUAL data-storage medium (a table), rather
than a lengthy string expression that gets tagged to a form or report's
Filter property (a bit unorthodox, I'll admit). Heck, I'll probably end up
going with the idea even if I don't reach the practical limit of the string
expression, because it's so logical.

Thanks for the suggestion.
Paul Johnson

"Jeff Boyce" -DISCARD_HYPHEN_TO_END wrote in message
...
Paul

I believe there is a maximum string length for a SQL statement, so I can
see
how saving 1 (or 3) digits could help with your approach. I'm wondering
(speculation only) if another approach could eliminate the need for that
portion of the string altogether... My thoughts (untested) are slanted
toward the use of a temporary table that holds the (multi-)selected
listbox
row IDs. Then it seems you could use a join to that temp table (list) of
IDs. Just a thought...

"Paul Johnson" wrote in
:

is from my developer's standpoint, I use the field in WHERE conditions
like "ReportID IN (12345, 12346, 12347, 12377, 23466, 43566, 23434,
54545, 56565, ... etc)" that may have up to a hundred records
(hand-picked by the user in a multi-select listbox).

A much better solution is to put the required IDs into a (temp) table and
joining it to the first one -- this is faster and gets round all the
arbitrary string length stuff.

PS -- how do you train your staff to handpick a hundred records with a
mouse?

HTH


Tim F

Selection can go quickly when you sweep the mouse through the listbox.

Paul Johnson

"Tim Ferguson" wrote in message
...
"Paul Johnson" wrote in
:

is from my developer's standpoint, I use the field in WHERE conditions
like "ReportID IN (12345, 12346, 12347, 12377, 23466, 43566, 23434,
54545, 56565, ... etc)" that may have up to a hundred records
(hand-picked by the user in a multi-select listbox).

A much better solution is to put the required IDs into a (temp) table and
joining it to the first one -- this is faster and gets round all the
arbitrary string length stuff.

PS -- how do you train your staff to handpick a hundred records with a
mouse?

HTH


Tim F

We have a fundraiser out here, where a cow is used to select
a numbered square on a football oval...

(david)

"Tim Ferguson" wrote in message
...
"Paul Johnson" wrote in
:

is from my developer's standpoint, I use the field in WHERE conditions
like "ReportID IN (12345, 12346, 12347, 12377, 23466, 43566, 23434,
54545, 56565, ... etc)" that may have up to a hundred records
(hand-picked by the user in a multi-select listbox).

A much better solution is to put the required IDs into a (temp) table and
joining it to the first one -- this is faster and gets round all the
arbitrary string length stuff.

PS -- how do you train your staff to handpick a hundred records with a
mouse?

HTH


Tim F