Declaration of Excel.Application object causes error (front-end)

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hello all.

I developed an Access application for some reporting purposes, and thought
it was a good time to split the database to enable some colleagues to have
access to the database data through the application's forms.
For the development i used Access XP (English, language is an issue here).

After having done the splitting, and while testing the front-end .mdb file
(with the forms etc.), i came across the following situations/errors, and i
would be grateful to receive some expert insights/comments:

1. Access XP does not want to open an .mdb file located in the intranet.
The error message i kept getting had to do with 'security reasons' and
'untrusted site'.
So i installed Access 2000 instead and simply bypassed the problem.
Is that a standard behaviour of Access XP?

2. While testing the front-end forms on a machine running *Greek* Access
2000, i got an error message for the declaration (VBA code):
Public AppXL as Excel.Application
(i'm doing some manipulation of Excel in my Access VBA code)

I never got this in the original file (before the split), and the reference
to MS Excel is properly set in the original file.
Does the reference need to be set again for the front-end part after the
split?

3. I'm also getting error messages for little parts of code involving the
Format statement, such as:

strDate=Format(BoxDate.Value,"mm/dd/yy")

I guess it has to do with the English characters being used for the
formatting ("mm etc.).

As the front-end might run on PCs with either the English or the Greek
Access, i'm wondering:
Is there a standard, intelligent way (Public VBA function?) to check for the
language being used, and define the String ("mm/dd/yy") used inside the
Format expression accordingly?

Many thanks for your time and patience,
Alex
 
Hi.
The error message i kept getting had to do with 'security reasons' and
'untrusted site'.
Click to expand...

Look at the path of the back end MDB file. Do you see any periods
(particularly if you are using the IP address of the server) in the file
path? If so, that will cause the "not a trusted site" error message in
Access 2002. (It's a known bug.) Use the UNC naming convention when linking
these tables, instead. If the back end is on a server which is located in a
different Windows network domain than the front end file, that will cause
this error message, too. And if the back end truly is located on a server
that is not a trusted site, then one may expect this error.
Is that a standard behaviour of Access XP?
Click to expand...

Not really. It's standard behavior for Internet Explorer due to Microsoft's
"trustworthy computing" policy. Internet Explorer is tied so tightly into
the operating system that the security zone settings for Internet Explorer
apply to network paths for Microsoft Office XP applications. (No other
version of MS Office checks these zones, so that's good news for people using
the other versions.) It's most noticable in linked tables where the tables
are located in an MDB file on a networked file server.
I never got this in the original file (before the split), and the reference
to MS Excel is properly set in the original file.
Does the reference need to be set again for the front-end part after the
split?
Click to expand...

You've made changes, such as splitting the database and using a different
version of Access, which very likely references libraries in different
directories than Access 2002 did, so check to ensure that there are no
missing references for the front end (and the back end, too, if you have code
in the back end).
3. I'm also getting error messages for little parts of code involving the
Format statement, such as:

strDate=Format(BoxDate.Value,"mm/dd/yy")

I guess it has to do with the English characters being used for the
formatting ("mm etc.).
Click to expand...

You didn't mention which error number and error message you received, so
I'll hazard a guess that it's more likely to be due to a missing reference
problem. Ensure that there are no missing references first before you start
fiddling with the date format.
Is there a standard, intelligent way (Public VBA function?) to check for the
language being used, and define the String ("mm/dd/yy") used inside the
Format expression accordingly?
Click to expand...

Unfortunately, dates in Access were originally designed to be used only with
the American date format, so applications designed to be distributed in mixed
languages/date formats are going to be a headache. It's probably best to
stick with just one date format for both languages (I know that's being lazy,
but there's something to be said about intentionally avoiding known
headaches).

HTH.
Gunny

See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips.

(Please remove ZERO_SPAM from my reply E-mail address so that a message will
be forwarded to me.)
- - -
If my answer has helped you, please sign in and answer yes to the question
"Did this post answer your question?" at the bottom of the message, which
adds your question and the answers to the database of answers. Remember that
questions answered the quickest are often from those who have a history of
rewarding the contributors who have taken the time to answer questions
correctly.
 
Hi,
2. While testing the front-end forms on a machine running *Greek* Access
2000, i got an error message for the declaration (VBA code):
Public AppXL as Excel.Application
(i'm doing some manipulation of Excel in my Access VBA code)

I never got this in the original file (before the split), and the
reference
to MS Excel is properly set in the original file.
Does the reference need to be set again for the front-end part after the
split?
Click to expand...

better to use late bindings in order to avoid compatibility issues
look here:
http://www.granite.ab.ca/access/latebinding.htm
 
Back
Top