Replies

If using my example it should be
LockForm(me, TRUE) to lock the form
or
LockForm(me, FALSE) to unlock the form

The problem that you have with your expression is that you have not used the correct syntax.

The first thing that you should probably do, is display the properties of the field that you wish to have the conditional formatting for. Then on then Event tab, double click next to the Got Focus event and then click the ellipsis button (the one to the right with three dots (…)). This will take you to the Visual Basic window for the Got Focus event of the control.

It will probably look something like this

Private Sub Name_GotFocus()

End Sub

Between these lines you will want to put your values that change the background colours of the phonenumber and fax number controls

This would look something like this:

PhoneNumber.BackColor = 255
FaxNumber.BackColor = 255

So the complete part of this will look like this

Private Sub Name_GotFocus()
PhoneNumber.BackColor = 255
FaxNumber.BackColor = 255
End Sub

So what this would do, is that when the Name field gets the focus, the PhoneNumber and FaxNumber fields change their color to red. I’m not entirely sure why you are wanting to do this, but hey this should work if that is what you are trying to do.

One last thing, as that I guess that you wish for these fields to return to their orginal colour when the Name control looses the focus again. So, you need to follow a similar proceedure for the Name control for it’s Lost Focus event.

The LostFocus event for the Name control would look similar but have the background colour of the phonenumber and faxnumber controls put back to whatever colour they were orginially.

Hope that this spreads some light on your problem.

Just as a sort of related aside, talking about users deleting tables…etc

It is always good to set the ‘statup’ option to show the database window as FALSE, and most users don’t know to press F11 to bring it up (and usually those users that do have enough sense to not delete stuff).

Why is the server logged into the database? This seems like and odd thing to have happening.

Is there a reason for this or is it unexplained?

try something along the lines of

Public Function LockForm (frm as Form, blnLocked as Boolean)
dim ctl As Control

frm.AllowEdits = not blnLocked
For each ctl in frm.Controls
ctl.locked = blnLocked
Next ctl
End Function

You need two pass to variables to this function.
frm is the actual Form object (not just the form name)
blnLocked the value TRUE or FALSE depending on whether you wish to lock the form or unlock the form

Give this a try. Hope that it helps.

http://www.msdn.microsoft.com

Use a consisten directory structure through all your ‘rollouts’.

ie. always put your databases that contain data in c:databasedata for example

This reduces the administrative overhead because all your rollouts exist on users machines in the same location and it means you can standardise your databases when distributing then (ie. to always point to c:databasedata

It means that you can split your data from your ‘front end’. If you want to upgrade the database you by distributing an update, you don’t want the user to loose all their data.

By having the data in a seperate .mdb file you can happily update their front end application database without replacing the data (as long as your data structure remains constant).

I’m sorta just thinking out loud here

I would check

1. When you exit the database is there a .ldb file in the same directory as the database?
yes? someone else is in the database and this may be causing problems?
no?

2. Can you export any other tables?
yes? can you run a make table query from the table and then export the ‘new’ table ?

3. How are you actually trying to export it?

At the risk of stating the obvious…why don’t you just set these properties to true again?

I have a specially designed database that I use to control all this. This database has a list of all the databases that we have, and by selecting the database name and selecting the’allow’ or ‘dissallow’ button, one can enable or disable the bypasskey when desired.

For proper production databases, the development versions have the AllowByPassKey set to false, and this property is only set to true when the new version is ‘rolled out’ and put into production. Again we can remove the setting by using the ‘control’ database if required.

Hope this helps

Hi Dave

I would use the Close event of form a and then pass a reference from the control on form A to the control on form b … ie.

Private Sub Form_Close()
forms!formBname.formBcontrolname = _
me!formAcontrolname
End Sub

Make sure you replace the italics with the appropriate form or control names.

Sorry, I was a bit unclear. I never use a sizable border on a form. I only set it to that to ‘resize’ it in form view, and once I have the size, I go back to design view change it to something that isn’t ‘sizeable’.

It may be very well that saving it in ‘form’ view doesn’t do anything, and that in fact it is when I return to design view and save it that it actually stores the size setting…but I have never bothered to go through it step by step and work it out (lazy I told you) – so I guess that step may be more ‘superstition’ than anything.

Oh well, maybe now I might actually find out if it does do anything or not?

J

I saw this post and thought that I could add my .

I always like to use a slightly different background colour for controls that are ‘required’ (ie. a pale blue or yellow). This indicates to the user that the field is required, and they know this instinctively from the colour of the field (not by trial and error).

Second, I accept Wendell’s point about checking each field, but with lots of ‘required’ fields this can become tiresome and easy to miss (just call me lazy).

I like to use the ‘tag’ property of controls to indicate those controls that have ‘required’ data. I usually set the tag property for controls to 1 for required and 0 for optional (or sometimes leave it blank).

During the beforeupdate event of the form, I just run code that loops through all controls, checks to see if the first character of the tag control is 1, if it is, it then checks to make sure that the field has a value. If the field does not have a value then the code sets a boolean (yes/no) variable to TRUE and changes the background colour of the control (so that the user can easily see the field/s that they were were meant to populate.

An example of the code would look like this

Dim ctl as Control
Dim blnFieldBlank as Boolean

blnFieldBlank = FALSE
For Each ctl In Me.Controls
if left(ctl.tag,1) = “1” then
if isnull(ctl.value) then
blnFieldBlank = TRUE
ctl.backcolor = your highlight colour code
Else
ctl.backcolor = your required colour code
End If
End If
Next ctl

if blnFieldBlank then
msgbox “You have not entered data into required fields. ” & vbcrlf & _
“These fields are highlighted.”, vbInformation, “Required Data Not Entered”
Cancel = TRUE
End If

Hope that this gives you some more ideas on it

I always set my borders of my form initially to ‘sizable’. I then go into ‘form’ view of the form, re-size the form to the size that I want it, save it from ‘form’ view, go back into design view, change the border style to ‘thin’ or ‘dialog’ (or sometimes ‘none’), then save it from design view.

Viola, this seems to work for me, sounds a bit pedantic, but hey….it saves stuffing around ‘guessing’ the size in design view and having to move back and forward between the two.

Jayden

Hi

I wonder if your problems with recordsets arise from using the right reference to DAO rather than ADO.

Step 1. From the VBA window , In tools —> references make sure you have ADO 3.6 checked
Setp 2. Explicity declare your database and recordset variables as DAO

ie.

Dim dbConnect as DAO.Database
Dim rstConnect as DAO.Recordset

This may help?