Solo712.
Before we go any further I think there is something which should be mentioned.
At least one of the moderators of this site thinks that the Watercooler forum should be treated with a great deal of tolerance but that level of tolerance does not apply to the technical forums.
Things such as:-
>>Just in case I am not the only one who thinks Rain's mostly talking through his hat.<<
and:-
>>an all-important point which you don't get<<
and:-
>>do yourself a favour and read a bit on winapi file lock/unlock functions.<<
can be read as both offensive and arrogant. So may I suggest you change your posting methods before some moderator takes action?
-----------------------------
I don't mind getting under people's skin, especially if they appear too smug.
A lot of technical arguments are based on false assumptions.
Pray, tell !
One of the false assumptions is that the programmer owns, or has the right to modify, the machine on which their program may run. In the business world that assumption is almost always false.
What are you talking about ? I own some of the machines on which I program. And, hell, I will program pretty well any way I please. I will certainly not be constrained by the lack of imagination of some people just because they think of themselves as experts.
In the business world there are two fundamental differences. The first, and more common, is that we go to work and use our company’s machines. The second, and less common, is that we send our program to a client for it to run on their machine. In both cases, though, our program is not running on our machine.
Really ? Never knew that ! And what did you say 'the two fundamental differences' were ? It's kind of hard to figure, you know ?
It therefore becomes a process of least interference with a machine which is owned by someone else.
What becomes 'a process of least interference with a machine which is owned by someone else ' ? And how does it follow what you said before ?
Of course we need to interfere with their machine to some degree, else we could not put our program on their machine, but the interference needs to be minimised.
Maybe, you should have tried this snotty, witless babble thirty four years ago when I started with computers. Maybe I would have been impressed, though I doubt it. I am a retired IBMer. Before IBM I wrote commercially/professionally succesful programs. Among them my own DB library built on the Btrieve engine.
For example, we should not change regional settings, write things to the registry, change screen resolutions or dump needless files to their machine. Another way to look at it is; how does the user totally cleanup their machine if they want to remove our program?
So it’s not just a matter of installation but also a matter of cleanup if the user wants to do so. Keeping the interference minimised also means keeping the changes to their machine internal to our program. Having external files created only helps to spread the footprint of the installation.
The only way for me to describe
politely what you are saying, is
stupid. It is you and your buddy Des who are talking down to people here, so obviously sooner or later you will run to people like me who will talk back to you - especially when they see there is much less there than advertized.
I see no reason why an intelligent Access applications designer would characterize external files the way you do. Yes, they add an element of system maintenance, and that element of course should be weighed against the benefit they provide. But they are system resources, no different than say, the WinAPI or the registry. Whether they should be used or not is not not a matter of some simplistic "you should never", "you must avoid", or some pre-concieved notions of what is allowed and what is not. It is strictly why should they be used in preference to something of equivalent effect but lesser cost.
The DMax() + 1 or DMax() functions may not be necessary; there are other ways to do it. The primary reason for doing any solution is not to return a known value but to return a unique value. The fundamental way to return a unique value is to have the unique value in the table set to no duplicates. It does not matter if the key is single or compound, the same still applies, we let the table decide if the key is in violation of duplicates.
I guess you still remember the argument we had about the domain aggregates vs unique compound indexes. Funny, out of the legion that rose with flaming swords against me noone showed up to defend the idea when similar requests were made afterwards. (lastly
here.) Funny also to see you defending methods that are by your own reckoning "not necesary" and contradict your own philosophy.
Ultimately, though, the violation of duplicates error is caught in the Form_Error event. Now there is a lot of stuff written on the www which states we should prevent errors before they happen. While in most cases that may be true, this is not one of them. We could write volumes of code to try and prevent that error, and all of that code may have its own error, but nothing we can write will even come close to the protection offered by the table violation and the error raised by it in the Form trying to do it.
In essence then, the Form_Error event becomes the ‘final frontier’ for the duplicate error. It bypasses all our efforts to prevent the duplicate error and simply reports the failure. How we handle that error is up to us but the fact still remains we will not be able to ignore it.
What you say does not make sense to me. Of course it is better to prevent an error if you can, always better than dealing with the consequences. Always, in everything. This is as much true about looking before stepping into shit, as it is in preventing DB errors which may cause - as the saying goes - an indeterminate state of the machine. To hell with your final frontier. If there is a way of preventing two users contending for table insert at a reasonable maintenance cost, you should do it - period.
Now it becomes the way to handle that error…
DMax() + 1 would not generally raise the error and would therefore bypass the Form_Error event. That may be seen as a good thing but is it really? It could work for many years without the need for the Form_Error event protection.
On the other hand DMax(), without the increment, will raise the Form_Error event under all conditions of unique key violation. So the fault condition is raised each and every time the update violates the table unique key. We do not have to wait for an error to occur over time in order to test the error. We create the error in the first place and therefore have only one path of recovery from that error to test.
This is obscurantist logic which is impossible to follow. Why would I be assigning DMAX() value to a key during an insert ? And the Form_Error with DMax() + 1 you do not need unless you want to have your own messages. Did you not just say, let the system handle it ? It handles it without the need for Form_Error. Why do you want to mess with the engine ?
Again in essence then…
Use the table to create the error of violation of unique key and use the single path of recovery in the Form_Error event.
Chris.
Looks like another one who has to wear sunglasses when gazing at his programming navel not to be blinded by the dazzle !
(no hard feelings though !
)
Best,
Jiri
. 
