472,101 Members | 1,420 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 472,101 software developers and data experts.

Help: 'trim()' Function not recognized

I created a church database in Access 97 that contain the typical Name,
Address, and Phone Number information fields. I had a number of
different reports to print query data in different formats.

I had a number of textboxes in the report designs that used the trim()
function to suppress printing of leading spaces. As an example, one of
the textboxes had the following:
=Trim([Address])
Basically, this is looking for a situation where someone accidentally
created spaces at the beginning of the address field and the report
suppresses the leading spaces for appearances. All the textboxes used
the trim() function which include some boxes that concatenated several
fields together.

The problem is that when the database were moved to two other computers,
one worked correctly; the other one didn't.

One system is XP, the other is 2000. Both are running identical version
of Access 2002 (10.4302.4219) SP-2. The database was converted to Access
2002 file format by the Windows 2000 system and works correctly. The XP
version does not; it apparently thinks 'trim()' is a variable and
requests an input value from the user. The two databases are identical
(byte for byte). The options for Access on the two systems are
identical.

I suspect that something is not loaded correctly or not loaded at all on
the XP system but I don't know where to look. I thought I should have
some of idea of what the real problem is before I blindly reload Access
on the XP system.

Any ideas would be greatly appreciated.

Thanks,
Dave

********************************
Dave Bovey
de*****@netzero.com
********************************
Nov 12 '05 #1
5 10331
Your references could be messed up.

This can be caused by differences in either the location or file version of
certain files between the machine where the application was developed, and
where it's being run (or the file missing completely from the target
machine). Such differences are common when new software is installed.

On the machine(s) where it's not working, open any code module (or open the
Debug Window, using Ctrl-G, provided you haven't selected the "keep debug
window on top" option). Select Tools | References from the menu bar. Examine
all of the selected references.

If any of the selected references have "MISSING:" in front of them, unselect
them, and back out of the dialog. If you really need the reference(s) you
just unselected (you can tell by doing a Compile All Modules), go back in
and reselect them.

If none have "MISSING:", select an additional reference at random, back out
of the dialog, then go back in and unselect the reference you just added. If
that doesn't solve the problem, try to unselect as many of the selected
references as you can (Access may not let you unselect them all), back out
of the dialog, then go back in and reselect the references you just
unselected. (NOTE: write down what the references are before you delete
them, because they'll be in a different order when you go back in)

--
Doug Steele, Microsoft Access MVP
http://I.Am/DougSteele
(No private e-mails, please)

"Dave Bovey" <La*********@yahoo.com> wrote in message
news:40***************@netzero.net...
I created a church database in Access 97 that contain the typical Name,
Address, and Phone Number information fields. I had a number of
different reports to print query data in different formats.

I had a number of textboxes in the report designs that used the trim()
function to suppress printing of leading spaces. As an example, one of
the textboxes had the following:
=Trim([Address])
Basically, this is looking for a situation where someone accidentally
created spaces at the beginning of the address field and the report
suppresses the leading spaces for appearances. All the textboxes used
the trim() function which include some boxes that concatenated several
fields together.

The problem is that when the database were moved to two other computers,
one worked correctly; the other one didn't.

One system is XP, the other is 2000. Both are running identical version
of Access 2002 (10.4302.4219) SP-2. The database was converted to Access
2002 file format by the Windows 2000 system and works correctly. The XP
version does not; it apparently thinks 'trim()' is a variable and
requests an input value from the user. The two databases are identical
(byte for byte). The options for Access on the two systems are
identical.

I suspect that something is not loaded correctly or not loaded at all on
the XP system but I don't know where to look. I thought I should have
some of idea of what the real problem is before I blindly reload Access
on the XP system.

Any ideas would be greatly appreciated.

Thanks,
Dave

********************************
Dave Bovey
de*****@netzero.com
********************************

Nov 12 '05 #2
> The problem is that when the database were moved to two other computers,
one worked correctly; the other one didn't.


This is likely a "references" issue and the following page at Doug Steele's web
site should help you out:

Access Reference Problems
http://members.rogers.com/douglas.j....nceErrors.html

--
Bruce M. Thompson, Microsoft Access MVP
bt******@mvps.org (See the Access FAQ at http://www.mvps.org/access)
NO Email Please. Keep all communications

within the newsgroups so that all might benefit.<<
Nov 12 '05 #3
Classic "Missing Reference" syndrome :-)

In the code window of the affected machine, select Tools->References,
see which is missing and fix.

--
A)bort, R)etry, I)nfluence with large hammer.
Nov 12 '05 #4
Have a look at Tools then References from a VBA module window. You may
find something is missing on your new PC.

Dave Bovey <La*********@yahoo.com> wrote in message news:<40***************@netzero.net>...
I created a church database in Access 97 that contain the typical Name,
Address, and Phone Number information fields. I had a number of
different reports to print query data in different formats.

I had a number of textboxes in the report designs that used the trim()
function to suppress printing of leading spaces. As an example, one of
the textboxes had the following:
=Trim([Address])
Basically, this is looking for a situation where someone accidentally
created spaces at the beginning of the address field and the report
suppresses the leading spaces for appearances. All the textboxes used
the trim() function which include some boxes that concatenated several
fields together.

The problem is that when the database were moved to two other computers,
one worked correctly; the other one didn't.

One system is XP, the other is 2000. Both are running identical version
of Access 2002 (10.4302.4219) SP-2. The database was converted to Access
2002 file format by the Windows 2000 system and works correctly. The XP
version does not; it apparently thinks 'trim()' is a variable and
requests an input value from the user. The two databases are identical
(byte for byte). The options for Access on the two systems are
identical.

I suspect that something is not loaded correctly or not loaded at all on
the XP system but I don't know where to look. I thought I should have
some of idea of what the real problem is before I blindly reload Access
on the XP system.

Any ideas would be greatly appreciated.

Thanks,
Dave

********************************
Dave Bovey
de*****@netzero.com
********************************

Nov 12 '05 #5
Many thanks for all the responses. One good answer is worth a thousand
guesses!

Thanks,
Dave

Dave Bovey wrote:
I created a church database in Access 97 ...

********************************
Dave Bovey
de*****@netzero.com
********************************


Nov 12 '05 #6

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

reply views Thread by mcp6453 | last post: by
1 post views Thread by Manu Ashok | last post: by
2 posts views Thread by Chris Millar | last post: by
1 post views Thread by Rahul | last post: by
7 posts views Thread by William (Tamarside) | last post: by
5 posts views Thread by jrod11 | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.