Just to explain why Paul's suggestion is a good one, VBA function and subroutine syntax can be ambiguous with respect to parentheses. There are times when you need them and times when you don't.
Consider this sample:
MsgBox "No credit available", vbOKOnly
You are using an IMPLIED "Call" and you are discarding the result of the function.
On the other hand,
iAnswer = MsgBox( "Press OK to continue or Cancel to abort", VBOKCancel )
Here you are expecting to use the value returned by the MsgBox function, which will tell you whether the user clicked the OK or the Cancel button.
But this case is neither fish nor fowl:
If IsNull( Me.EmpID ) Then MsgBox("No Credit Available", vbOKOnly)
After the "Then" keyword, the next item is a statement, which in this case begins with an identifier ("MsgBox") followed by parentheses that make it look like you are worried about the return value - but there is no place to PUT that return value. Which is why it wants the equals sign. Essentially, VBA is confused by a statement that does, but does not, want the value of the function.
I have a different take on this, though. Using this syntax,
crname = Me.EmpID.Value
I'm not sure WHAT you'll get back.
First, you don't need the .Value since for any statement that appears to be an expression, .Value is the default property. But we can let that slide.
Second, you are executing this in the Form_Load routine, which fires BEFORE the Form_Current routine. That means that you would never see any value there. But I don't know that you would ever see a null in that case, either. You MIGHT see an empty string. If I were coding that (in some other event than _Open or _Load), I might use
If Nz(Me.EmpID, 0) = 0 Then ...
' OR, if EmpID is mixed alphanumeric...
If Nz(Me.EmpID, "") = "" Then ...