Chr(0) throws and error (1 Viewer)

When I deploy my access application and I run it I get an error at this line:
GetLogonName = Left(lpBuff, InStr(lpBuff, Chr(0)) - 1)
It seems to have an issue with Chr(0).
Can you help please?

What does chr(0) mean to you? -that is what is your intent with -

Are you reading some file? If so could you tell us about the data in that file?

Chr(0) returns the Null character. I expect the code is looking to remove the last character from a Null terminated string if it is present.

The expression will throw an error is there is no Null in the string because Instr would return zero passing a -1 to Left().

When searching for an optionally present character, always concatenate the search character onto the end of the string to avoid errors if it isn't already present.

To be pedantically correct, Galaxiom, Chr(0) returns the NUL character, using the US-ASCII name for that particular bit pattern. We might colloquially call it Null, but it really isn't Null, it is NUL.

If Chr(0) actually returned a Null, then you would probably get "Invalid use of null" as an error. Speaking of which, ...

DanielR - you say you get an error and you told us where. But you didn't identify WHICH error you get. Please advise us.

The error came up when I deployed the access app to another machine using SSE Setup -> exe file install, etc.
I also got a missing: Microsoft office 15.0 object library
This might be causing the chr(0) error.

I have split the database into front end and back end.
I wound up creating a shortcut to the front end and coping that onto users machine and it works fine. No Chr(0) errors.

Missing references can raise strange errors since the first statement that executes looks like it fails.

Fix the broken reference and the error will go away.

Remember Access cannot demote references so if you develop in a newer version than your clients use, you will need to use late binding so you can avoid linking to specific libraries at compile time. OR, do your development in the lowest version that you need to distribute.

Microsoft will never address this issue unless people complain. It isn't a bug, it is by design but it would be so much better for developers if Access would demote references rather than just promoting them when necessary. So if you develop in O2013 and run in O2016, everything works fine. All the references are promoted to O2016. However, if you run in 02010, you will get unusual errors caused by the missing reference to some O2013 library because Access will not demote the O2013 reference to O2010. The assumption of course is that you have used some new feature that isn't available in the earlier version. I would prefer that the app fail only if a "new" feature isn't available because most of what I develop will run in earlier versions and I really hate being forced to use late binding. It is slower and you loose intellisense so early binding is bad for both the user and the developer.

I installed Microsoft runtime for access2013...I developed the app in access 2013. They should have been in line with each other. How do you perform late binding? Would that just be going into the reference section of the app and binding?

You are referencing some Office component so you need to have Office be 2013 as well as Access.

Post the code that needs the reference and someone will help convert it to late binding. You have to change the way the object is defined and the way it is instantiated. You will also have to change any code that references variables from the library.

The user has office 2013 installed.

No worries...I just copied a shortcut of the accdb file to the users desktop.
Works fine.

Thank you for the help.