Replies

Having your temp directory in a >2 gig partition is irrelevant. Until recently, my 10 gig drive had only one partition on it, taking up the whole 10 gig, and I use Office 97 a lot.

To get “stretchy” vertical lines that go the depth of the section, you actually have to draw them yourself. Following is a standard routine I use in my databases that draws a line on top of any existing line whose name starts with “vline”. Note that it must be called in the Print event code of the detail section of the report in order to work correctly. Call it with Call DrawVline(me)

[indent]

---

Public Sub DrawVLine(ByVal Rept As Report) ‘Rept will invariably be Me
Dim cLine As Control ‘For stepping through every control in the report
Dim xPos As Single ‘x coordinate of line (in twips)
Dim yHt As Single ‘y height (in twips)

For Each cLine In Rept.Controls ‘Step through every control in report
If cLine.ControlType = acLine And Left(cLine.Name, 5) = “vLine” Then ‘Find all lines named vLine…
xPos = cLine.Left ‘x position of line
yHt = Rept.Height ‘height of section
Rept.Line (xPos, 0)-Step(0, yHt), 0 ‘Draw vertical line at xPos,0 of height yHt in black (colour 0)
End If
Next

End Sub

---

[/indent]

No – you make a key sequence, prompt, magic button, or whatever to set allowbypasskey back to true again (look at the code for turning off allowbypasskey; it should be apparent how to turn it back on again). Then the next time you open the database you’ll be able to use the shift key as usual to bypass the startup conditions.

So, no, you’re not making a key to take the place of the shift key; you’re making a key (button, prompt, or whatever) that allows you to use the shift key again!

That’s up to how you choose to implement a “back door”. You need to choose a way to allow certain users to run code that sets allowbypasskey back to true again.

The way I deal with it is to check either currentuser() if I am doing something that uses workgroup security, or the NT id if I’m doing something that doesn’t use workgroup security, and if they belong to a set of “special people” I prompt to see if they want the shift key turned back on (i.e. allowbypasskey set back to true) for the next use of the database. If you have no “special users”, then you’ll have to use security by obscurity; for instance watch some special key combination done in some particular place.

I also always make sure allowbypasskey is turned off everytime the database is started normally, so there’s no need for the “special users” to remember to do something special to turn it off again.

Just an observation to anyone proposing to use environment variables to get the username – I hope you’re not planning to use it for any sort of security; what’s to prevent someone from changing the environment variable? If you’re using Windows NT or Windows 2000, using the code that has been posted several times will be a lot more secure.

I’ve had intermittent problems with database corruption in Access 97 almost from day 1. After much grief and serious swearing at my computer I came to the realization that even minor changes to forms and reports while others are using the database (even if the others don’t even look at those forms or reports) is a major gamble. I’m assuming that that restriction was put in Access 2000 specifically to prevent that problem.

You can catch swear words that have prefixes or suffixes (what I think you were getting at with *******) by simply not including leading and trailing blanks in your search terms. HOWEVER, if you do so you will occasionally see false positives (i.e. words that aren’t swear words but that just happen to have “naughty letters” within them). I don’t recall examples, but there have been a few cases mentioned in the comp.risks newsgroup that involved going overboard with swear word checking. There’s also cases where a swear word isn’t a swear word in certain contexts. (I do believe Woody’s Lounge is doing some censoring, judging from what happened when I entered that word without spaces!)

As long as you’re manually checking the records that your program flags you’re probably all right, but I wouldn’t try to automate the record deletion!

Go to Tools | Autocorrect. You now have two choices; either uncheck Replace text as you type to disable all substitutions, or scroll down to the offending one (blase in your case), select it and click Delete.

I seem to recall that the same autocorrect information is used throughout Office (I’m sure somone will correct me if I’m wrong ), so you’ll be changing how your copy of Word behaves as well.

No, a checkbox doesn’t need to be bound to a field to be useful. If you want the value of the checkbox remembered from session to session then you’ll likely want it bound to a field somewhere. However, if you are just using it to indicate an option for your current session (e.g. whether to preview or print a report) it doesn’t need to be bound. Just retrieve its value (True/False) in the code for your form (e.g. in the code behind the button that either prints or previews).

Simplest way would be go to Tools | Startup… There you can set the initial form, turn off the database window, block the “special keys” (e.g. F11 to display the database window), and a few other things.

Note that the user can circumvent this by holding down the shift key when starting the database (that will also prevent an autoexec macro from executing). If you’re trying to use this for security, you’ll need to block the shift key (the code for that has been posted a few times recently).

The most reliable way of ensuring that the database goes away when the form closes would be to stick Application.Quit in the code for the Close event of the form.

If you can get your supervisor to fork over the $, get Total Access Analyzer (click on the name to go to a description of it). Among many other things it will give you many different types of cross-references of your database. Also handy if you’re cleaning up “messes” created by others is the fact that it provides a detailed breakdown of problems in your database.

Try

(Lira+500)1000

Note that is the integer division operator (i.e. it does division and throws away the fractional part).

Validation rules are easy to work with (although there are limits to what you can manage to check just with validation rules). Check out the builtin help on validation rules.

There’s an excellent chance that the id you want is “admin”. That is the default id in Access; whenever you start Access if it finds that admin has no password it doesn’t prompt you for an id and password. You seem to have been playing with user and group security rather than just setting a database password.

The users and groups (and their passwords) are stored (in an encrypted form) in your system.mdw file, the default workgroup file used by Access. Since it is the default, that’s why every time you use Access you are getting prompted for an id and password.

I assume you remember the password you were trying to set. Open any database, specifying “admin” and whatever that password was. You might get asked for another password after that (if you managed to also set a database password on the database you’re opening). Hopefully you were consistent in the password you were trying to set! Once you’re in, go to Security | User and Group Accounts…, make sure “admin” is showing, and click “Clear Password” (that should be right for A2K; I’m running A97 at this instant – it’ll be similar if not the same). Once admin no longer has a password you won’t be prompted for an id any more.

You didn’t say what the difficulty was so this may be totally irrelevant; however, try putting in me.repaint after setting the visible properties to see if that makes it work better.

If that doesn’t help, be more specific about what your problem is.