Replies

I’ll leave it to others to show you the input masks/formats/whatever. However, you said you wanted the day to be stored as 01. The credit cards that I’ve run into expire on the last day of their expiry month, not the first day. So, if you are doing date comparisons to check whether a card is valid, you’ll want to either store the last day of the month or the first day of the next month.

Oops! I was about to argue with you until I realized that I was confusing the Dirty event (new in Access 2000) with the Dirty property. Sorry.

The rest of my comment still stands. If the form isn’t “dirty” the beforeupdate event won’t fire, so there’s no need to check if it’s “dirty”.

Two things – Me.Dirty is only available in Access 2000 (the original questioner didn’t say what version of Access they were using). Secondly, the beforeupdate event won’t fire if the record hasn’t changed, so you don’t really need to check me.dirty in the beforeupdate event.

No. See http://support.microsoft.com/support/kb/ar…s/Q131/5/35.asp (Skip to the third paragraph of the “More Information” part).

Define “wrong”!

Computers “like” to do arithmetic using the base 2 (i.e. binary) system. That’s no big deal for integers; what is an integer in one number system is an integer in any other number system. It DOES matter for floating point (i.e. fractions).

What is a repeating decimal in one base (e.g. 1/3 = 0.333333…. in base 10) is not necessarily a repeating decimal in another base. 1/3 in base 10 is 1/10 in base 3, which is 0.1 in base 3. 1/10 (or .1) in base 10 is 1/1010 in base 2, which is the repeating binary fraction .00110011….

That’s a long-winded way of saying that you’ll get rounding errors in floating point arithmetic on computers even where you might think that a particular fraction can be represented exactly.

There are often ways around that at a cost of efficiency or number range. For instance, if all you care about is 2 decimal places, you can multiply everything by 100 and work in integers (e.g. store cents rather than dollars). That’s basically how the currency type works except that it scales by 10000 rather than 100 to allow 4 decimal places.

PS Hey! I found somebody else with my initials!

I can’t answer your specific question, but just an observation; I use Me as a parameter to a global routine quite regularly and have never had a problem. In my case I use it to pass the current report, not the current form, but if it works for reports I’d hazard a guess that it works for forms. (I have a standard global routine for making vertical lines that “stretch” to the full depth of the report section that takes one parameter which is assumed to be a report, and all that I ever pass for that parameter is Me).

I don’t know the guts of Access that well, but my assumption has always been that the keyword Me must occur in form or report code but what Me contains can be passed wherever you want.

Yes, it sure would be nice to be able to turn off Access’s “second guessing”! IMHO it increases data-entry errors rather than decreasing them.

In any case, are all dates valid in your database or can you put in a validation rule to check for sensible years? That’s simpler than parsing dates yourself.

If you want identical records (other than autonumber fields), make yourself a second copy of your table and two append queries (one to copy from the first to the second and one to copy from the second to the first). Put a single record in the first table (or you could put several in if you want many repetitions of those multiple records). Repeatedly run your two append queries alternately until one of the two tables is the size (to the nearest power of two) that you want. Delete the second table.

For the hard limits in Access 97 (i.e. those that you can’t exceed), see limits, program in the built-in help. I assume there’s something similar in the Access 2000 help (I have both, but the way I’m set up requires me to re-boot to switch back and forth, so I’ll leave you to look ).

However, those limits just tell you what is guaranteed not to work. As Charlotte said, when you get into millions of records (I’d be dubious of even tens of thousands), you really want something more robust like SQL Server, Oracle, etc. How many millions (or tens of thousands) can’t be answered; it depends on your record sizes, database complexity, tolerance for sssslllloooowwwwnnnneeeesssssss, number of simultaneous users, etc. etc. etc.

Actually, Charlotte, I’ve got databases that do not convert using the automated method, but when manually converted (by importing and then moving the DAO reference up near the top of the reference list) compile and run fine. So, you may be right that there is some code that the automated method hiccups on, but that does not mean that the code won’t compile in A2000.

Charlotte – No, turning off “Use Access Special Keys” does not disable the shift key. It certainly doesn’t in A97 (I use both it and the AllowByPassKey property a lot). I’m 99% certain it also does not in A2000, but I’d have to double-check to be absolutely certain.

I’ve been testing the conversion of quite a few of our databases to Access 2000 (we’re planning on converting “for real” in the fall and we don’t want surprises). When the automatic conversion completes without errors I haven’t had to do anything about ADO; the conversion process does the appropriate things with the references.

If the automatic conversion fails (and I’ve had that happen several times) and you convert by importing everything, that’s when you need to watch your references or you’ll get lots of compile errors. Make sure (unless you want to make changes to your code) that the DAO stuff comes before (i.e. closer to the start of the list of references) than the ADO stuff. I haven’t tried turning off the ADO since it didn’t appear necessary once the order is right; I’ll have to look at that sometime.

I’d suggest going for Total Access Analyser as well. I’ve been using it in my databases. It has NUMEROUS reports (you can easily use hundreds of pages of paper documenting a complex database if you’re not very judicious about the reports you choose), and you should find something to approximate any sort of cross-referencing you want. It’s also very handy for checking for errors in your database.

Unfortunately, I have never felt that the demo did it justice.

I agree – remembering how to work with nulls takes some getting used to (although as I said in a previous message, explicit numeric nulls can be extremely useful in certain circumstances). It is documented in the online docs (although you might need some psychic talent to realize beforehand what you should be looking up ) – see “Comparison Operators” in the online docs.

When you need to work with nulls, keep the function nz(…) in mind; very handy where you do want to treat null as zero (or any other chosen value) in a specific place in your code.

Just an observation – my copy of Symantec Systemworks 2000 started bugging me about subscribing in order to get more virus updates. I simply set my computer’s date back a couple of months and it let me get the updates. Admittedly, I’ve only tried it once, but it seemed to work as expected; it definitely downloaded virus updates and those updates seemed to be new (based on the version date that it shows me).