Function causing errors

[cebrower]

I have a module containing a function copied from the 'net that returns the computer name of the computer using Access 2010 run-time and an Access 2010 accde front end. It works well on all the computers in our LAN except one. On that one computer it causes odd errors such as records with missing data, failure to recognize built in functions such as Left() and crashes when a variable is encountered. Sometimes an error message appears saying there is invalid use of the . (dot) or ! operator or invalid parentheses even though that is not the case. This function actually worked well on this computer until just recently when it started acting up. All the computers on the LAN are 64 bit running Win 10 Pro, some clean installs, some upgraded from Win 7. The code is as follows:



Option Compare Database
Option Explicit


Private Declare Function apiGetComputerName Lib "kernel32" Alias _
"GetComputerNameA" (ByVal lpBuffer As String, nSize As Long) As Long
__________________________________________________ _________________

Function fOSMachineName() As String


'Returns the computername
Dim lngLen As Long, lngX As Long
Dim strCompName As String
lngLen = 16
strCompName = String$(lngLen, 0)
lngX = apiGetComputerName(strCompName, lngLen)
If lngX <> 0 Then
fOSMachineName = Left$(strCompName, lngLen)
Else
fOSMachineName = ""
End If


End Function

I have a similar module that returns the user name. It looks like this:

Option Compare Database
Option Explicit


Private Declare Function apiGetUserName Lib "advapi32.dll" Alias _
"GetUserNameA" (ByVal lpBuffer As String, nSize As Long) As Long
__________________________________________________ ______________


Function fOSUserName() As String
' Returns the network login name
Dim lngLen As Long, lngX As Long
Dim strUserName As String
strUserName = String$(254, 0)
lngLen = 255
lngX = apiGetUserName(strUserName, lngLen)
If (lngX > 0) Then
fOSUserName = Left$(strUserName, lngLen - 1)
Else
fOSUserName = vbNullString
End If
End Function


If I delete the modules and all references to the functions the problems all go away. Any help would be appreciated.

[ranman256]

would this work:

Public Function getPCname()
getPCname = Environ("COMPUTERNAME")
End Function

[Welshgasman]

Would the errant computer be 64 bit Access at all?

[cebrower]

No, Access is the 32 bit verion.

[cebrower]

That does the job. I'll need to recompile the accde and copy it to the user to see if the errors go away. To get the user name do I just replace COMPUTERNAME with USERNAME?

[moke123]

heres a list http://codevba.com/office/environ.htm#.X62yHshKhhE

[DittoBird]

This is an interesting post for me. I have used those very same functions from Dev Ashish for many years in A2003, mostly. I wonder if he's still around?

Anyway, thanks ranman256 and moke123. How marvelous!
--
Tim

[cebrower]

Your suggestion resolved some issues, but this database won't recognize any of the built in functions like Left() or Round() etc. Again this problem only happens on this one computer. I've attached a shot of the references. Anything wrong there?

[Micron]

To recap - all pc's are running 32 bit Access and the db was created in a 32 bit version? Replacing your prior code (which was written for 32 bit) with environ variables could mean that you worked around what might have been needed - a 64 bit version of that code. Are you sure the problem pc is running 32 bit? I would not take anyone's word for it. From what I've read, people think your current issue could be bit related. Others suggest importing all objects into a new db if compiling code doesn't fix that issue.

EDIT - just read that there was a reported bug where this can be caused by an empty procedure such as

Private Sub Form_Load

End Sub

BTW, is the db an accde or mde, and on the problem pc, the db is located in a Trusted Location?

[Welshgasman]

Just as an aside I downloaded a DB today that kept giving me Format() errors.
It turned out that there was a missing reference to Outlook 16 and I only have 2007, but to be fair, it was marked as missing, whereas all yours appear to be present.

Removing that allowed the code to compile, and I have no idea what an Outlook library has to do with the Format() function.

So, you never can tell

[cebrower]

All PCs are running Access 2010 runtime sp1 32 bit. I installed them myself using the same installation file. Each computer also has Office 2010 Home and Office sp2 32 bit. The computers are Windows 10 Pro 64 bit, some upgraded from Win 7, some factory installed. I do the development using the full version of Access 2010 32 bit. My copy of the front end resides on our server. Whenever I make a change to the front end I recreate the accde file and copy it to a folder on the users PC. The back end is Access 2010 accdb and resides on a virtual server on a Dell server running Windows Server 2012. All locations are trusted. Everything has been running fine until a few days before I started this thread. That's when things started misbehaving on one PC. I do have a few procedures in which all the code is commented just in case I want to use them again sometime. Oddly, just before I read your most recent reply, I copied and pasted the accde from another PC where it was working properly to the troublemaker, and now it runs fine on that PC.

[Micron]

If you continue to have issues, what about automatic updates**? Possible that the problem pc is either ahead or behind the rest? Updates have been known to introduce failures - from what I've seen, usually on code that was a bit less than optimal and ran OK before but newer builds balked at. To be relevant, the problem pc would have to be running a more up to date build of Access I guess. Last stab at it for me, I think, is to ensure the user profile is the same as everyone else. Each user needs the same permissions.

If you fixed it by copying over a working copy to the problem pc and you did it from that pc, then under whose profile did you do that? If yours and the problem recurs before you issue a db update, that might indicate something as that copy would be operated under a different profile than the one used to copy it over.

** updates to Access, that is.

[cebrower]

Since my last post to this thread I've updated several other PCs form Win 7 to Win 10 and two of them have been giving error messages that make no sense. It's difficult to debug because the errors occur only on computers using Access run-time and accde databases. But after a lot of fuss and bother I found that the errors go away if I remove the reference to Microsoft Office 14.0 Access database engine object. One database had some functions with references to DAO recordsets, so I had to add the reference to the Microsoft DAO 3.6 object library in order to get it to compile. Hope this helps someone else avoid a lot of stress.

[isladogs]

Your errors may well make sense if the ACCDE file was compiled in a different version of Access to the runtime version.
The DAO 3.6 library reference dates back to A2003 and shouldn't ever need to be used with ACCDB/ACCDE files

[cebrower]

I do the programming (front end) using Access 2010 and then I create an accde database and copy it to every user. All the users are using Access Runtime 2010. The back end is an accdb file created in Access 2010 residing on a Dell server. If I select the references in my accdb database and the create an accde database from my accdb database, don't the references in the accde database match what was in the accdb database?

Most users computers are Core i5 or i7. A few of them a Xeon processors. The problem occurs on the Xeon machines, but not on all of them. Two machines are Xeon ES-1620. The problem occurs on one of them, but not the other. One machine is a Xeon ES-1607. It was fine until I upgraded it from Win 7 to Win 10.