Replies

They presumably do (otherwise there would be far less need to compact actively used databases regularly to avoid “bloat”), however no, there isn’t any way to get them back (other than possibly attacking the mdb file with a byte editor to extract the text; good luck – you’ll need it! )

Assuming you haven’t disabled the shift key (and it takes code to do that, so it’s very unlikely you would have done that accidentally), just open your database with the shift key held down. That temporarily disables your startup options. You can then turn “Allow full menus” back on.

In many cases it’s poor practice to put nulls in numeric fields, but I must butt in and say that there are cases where nulls are extremely useful in numeric fields! A previous database system that I used (4th Dimension on Macintoshes) had no provision for nulls and it was a royal pain in the a– to have to choose a particular “magic number” to use to signify missing data, remember to make sure it appeared blank in the output, make sure not to accidentally use it in calculations, etc. etc. In general, 0 and “missing” have radically different significance in most of the numeric fields I’m using in my databases.

Delete all the links to the tables in the back-end, and then import all the tables from the back-end.

Well, I eventually got to “USERNAME=DMartin” with environ(23) ! It does not look as though environ(number) is a very portable way to do anything, since it depends on a lot of things showing up in the same order every time.

Yes, there’s a way to get the NT User id (I’ll dig the code out of one of my databases if you want it), but not by using environ(9). All eviron(9) gives me is “NUMBER_OF_PROCESSORS=1”. I see from the on-line help that what environ(9) gives is simply the 9th string in the environment string table. Doesn’t sound too reliable for getting something expected!

Yes, only one mdb file is present regardless of how many people simultaneously use the database and normally goes away when the last person closes the database.

Normally, if you had a second session open then you’d see that in your task bar. To make absolutely certain you could always log off and back on (or reboot) again (never needed to with Access, but I’ve needed to with Word before).

If you know no one else is using the database, delete the mdb file and try again. If it is still doing it, then something is corrupted.

Why are you hard-coding a maximum number of drawings? It leads me to think you have everything in a “flat file” (i.e. everything in one table without related tables). How about setting up a related table that holds the drawing requests? You can then use a subform for the drawing information and either appropriate grouping in your report or subreports. That way, you see everything that was requested and only what was requested (i.e. no blanks).

You can. However, if you declare your variable as something specific (e.g. form, control, or whatever) and then type the variable followed by a period, Access is nice enough to show you what properties or methods can follow the period in that context. Also, if you goof and use a property or method that doesn’t apply to whatever you’re working with, you’ll get a compile error rather than a run-time error, and it’s a lot easier to find compile errors!

Declaring things as “object” means you don’t get those features.

A password cracker program worth its salt should have given you the clear-text password (otherwise it’s not very useful as a password cracker ). Are you sure the database isn’t corrupted? A corrupted database can appear as though it is password-protected.

Yes, it is very useful, but not specific to Like (probably why Susan didn’t mention it). As an example, you can enter something like BETWEEN [Enter from] AND [Enter to] to let the user specify a range, >=[Enter Minimum Value] to let them specify a minimum, etc.

The rules are additive – if any of them (control, field in a table, or table) fail, then the validation fails. So, no, you don’t need to put validation rules on your controls if they are already on the fields of your tables. Quoting from the Access 2000 help (and it also applies to Access 97):

[indent]

---

Order of validation for controls and fields
Validation rules for controls and fields are evaluated in the following order:

Macro or event procedure validation (for example, a macro or an event procedure that responds to the BeforeUpdate event of the control or the form containing the control)

The control’s ValidationRule property

The underlying table’s validation rules for the field (as set in the field’s ValidationRule, Required, and AllowZeroLength properties)

The underlying table’s ValidationRule property (this property performs validation on records)

---

[/indent]

I backed off to IE5.0 simply by uninstalling IE5.5 using the Add/Remove Programs control panel. It seems when you upgrade from 5.0 to 5.5 it keeps the old stuff around in case you need it again (maybe Microsoft was anticipating problems? ).

If you set disabled to true and locked to true, then the field is not grayed out and the users will not be able to land on those controls.

I’ve never tried this command line switch, but according to the online help (ask for help on command-line options) /x macroname will start a specified macro when Access starts up. So, you could use that to run your macro only when the scheduled task launches and not every time you run the database (as would be the case for the Autoexec macro).