A Microsoft Office (Excel, Word) forum. OfficeFrustration

If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

Go Back   Home » OfficeFrustration forum » Microsoft Access » Database Design
Site Map Home Register Authors List Search Today's Posts Mark Forums Read  

Reporting an incremented "ID" with a sorting requirement



 
 
Thread Tools Display Modes
  #11  
Old July 31st, 2008, 05:07 PM posted to microsoft.public.access.tablesdbdesign
Michael Gramelspacher
external usenet poster
 
Posts: 482
Default Reporting an incremented "ID" with a sorting requirement

On Thu, 31 Jul 2008 06:40:01 -0700, Klatuu
wrote:

That is not an unreasonable technique. I have seen it used also; however, it
all could be done with a DLookup as I do it to get the current high number
and an SQL Update query to save the new number back to the table.

Any time you can avoid using a recordset, you should. Not that recordsets
are bad, it is just a performance issue.

Also, when using Action Queries, the Currentdb.Execute method is the fastest
way to do it. It bypasses the Access UI and doesn't trigger warning
messages. But, because it doesn't go through Access, but directly to Jet,
you need to use th dbFailOnError option to be sure you get an error returned
if it fails.

But, there is one problem with your code. You are assuming the record will
be found. It will not always be, so you have to plan for that. It will not
be found for the first occurance of the maing designator and document type
combination.
--
Dave Hargis, Microsoft Access MVP


I saw the technique recommended for a multi-user enviornment, as a way to incure
every user would get a unique number. It is true that the first number needs to
be inserted somehow. Typically DMax is the method to use. No argument there.
  #12  
Old July 31st, 2008, 05:17 PM posted to microsoft.public.access.tablesdbdesign
Klatuu
external usenet poster
 
Posts: 7,074
Default Reporting an incremented "ID" with a sorting requirement

You are correct. It will ensure each user gets a unique number. The only
problem is that a gap in numbering could happen if a user starts a new
record, then does not save the record, the number is discarded. But, that
may not be an issue.

--
Dave Hargis, Microsoft Access MVP


"Michael Gramelspacher" wrote:

On Thu, 31 Jul 2008 06:40:01 -0700, Klatuu
wrote:

That is not an unreasonable technique. I have seen it used also; however, it
all could be done with a DLookup as I do it to get the current high number
and an SQL Update query to save the new number back to the table.

Any time you can avoid using a recordset, you should. Not that recordsets
are bad, it is just a performance issue.

Also, when using Action Queries, the Currentdb.Execute method is the fastest
way to do it. It bypasses the Access UI and doesn't trigger warning
messages. But, because it doesn't go through Access, but directly to Jet,
you need to use th dbFailOnError option to be sure you get an error returned
if it fails.

But, there is one problem with your code. You are assuming the record will
be found. It will not always be, so you have to plan for that. It will not
be found for the first occurance of the maing designator and document type
combination.
--
Dave Hargis, Microsoft Access MVP


I saw the technique recommended for a multi-user enviornment, as a way to incure
every user would get a unique number. It is true that the first number needs to
be inserted somehow. Typically DMax is the method to use. No argument there.

 




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Forum Jump


All times are GMT +1. The time now is 01:39 AM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright ©2004-2024 OfficeFrustration.
The comments are property of their posters.