I have two files that when an accde is created from these files, all
programming is unavailable. All of my other files work properly when an accde
is created from them. I do not know of any difference in these two files. I
have recreated the files, queries and forms. I linked to the tables that work
with the other files, but it still has the same problem. Please let me know
where to look.
--
Rick

I have removed two reports that when these are removed, allows the accde file
to be created properly. I do not know why a report would cause such a
problem. Especially when these are not even opened. Any ideas would be
appreciated.
--
Rick


"rbeach" wrote:

> I have two files that when an accde is created from these files, all
> programming is unavailable. All of my other files work properly when an accde
> is created from them. I do not know of any difference in these two files. I
> have recreated the files, queries and forms. I linked to the tables that work
> with the other files, but it still has the same problem. Please let me know
> where to look.
> --
> Rick

The problem was with the "Option Explicit" on the report. Once this was
removed, the accde file created properly.
--
Rick


"rbeach" wrote:

> I have removed two reports that when these are removed, allows the accde file
> to be created properly. I do not know why a report would cause such a
> problem. Especially when these are not even opened. Any ideas would be
> appreciated.
> --
> Rick
>
>
> "rbeach" wrote:
>
> > I have two files that when an accde is created from these files, all
> > programming is unavailable. All of my other files work properly when an accde
> > is created from them. I do not know of any difference in these two files. I
> > have recreated the files, queries and forms. I linked to the tables that work
> > with the other files, but it still has the same problem. Please let me know
> > where to look.
> > --
> > Rick

Has anyone else heard of this? I have never come across any situation where
I would remove an Option Explicit statement, for any reason whatsoever. In
fact, I don't think I ever would even if I thought I had a reason... far too
dangerous.

But, why would the code work during development, but not when transferred to
an accde? The need to remove the Explicit statement indicates problems with
variable naming, but for what reason would it not be caught in an accdb?
Maybe some sort of deeper db corruption?

Anyway, I've never heard of anything even remotely like this. I've always
thought one would be better off chopping their own head off than trying to
code without the Option Explicit.

So this post is a 2-part: 1) Rick - you may very well have a much deeper
problem than you think, and 2) Can anyone else shed some light on what might
cause this?


--
Jack Leach
www.tristatemachine.com

- "First, get your information. Then, you can distort it at your leisure."
- Mark Twain


"rbeach" wrote:

> The problem was with the "Option Explicit" on the report. Once this was
> removed, the accde file created properly.
> --
> Rick
>
>
> "rbeach" wrote:
>
> > I have removed two reports that when these are removed, allows the accde file
> > to be created properly. I do not know why a report would cause such a
> > problem. Especially when these are not even opened. Any ideas would be
> > appreciated.
> > --
> > Rick
> >
> >
> > "rbeach" wrote:
> >
> > > I have two files that when an accde is created from these files, all
> > > programming is unavailable. All of my other files work properly when an accde
> > > is created from them. I do not know of any difference in these two files. I
> > > have recreated the files, queries and forms. I linked to the tables that work
> > > with the other files, but it still has the same problem. Please let me know
> > > where to look.
> > > --
> > > Rick

On Wed, 25 Feb 2009 10:39:01 -0800, rbeach <(E-Mail Removed)>
wrote:

>The problem was with the "Option Explicit" on the report. Once this was
>removed, the accde file created properly.

NO IT WASN'T. It was created *improperly*.

If there is a compile error in your VBA code, you won't be able to create an
accde.

Removing the Option Explicit just sweeps your compile error under the rug!
There is still an error in the code - probably a reference to some variable
for which you have no Dim statement. Your code now contains a timebomb; some
unfortunate user will crash Access and close the database when they hit the
error in your code.

Put the Option Explicit back in; select Debug... Compile <my database>; *and
fix the error*. THEN make the .accde file.
--

John W. Vinson [MVP]

On Wed, 25 Feb 2009 16:14:00 -0800, dymondjack <dymondjack at hot mail dot
com> wrote:

>But, why would the code work during development, but not when transferred to
>an accde? The need to remove the Explicit statement indicates problems with
>variable naming, but for what reason would it not be caught in an accdb?
>Maybe some sort of deeper db corruption?

As I suggested in my reply, it may be that taking out Option Explicit is just
papering over the problem. If there is an un-Dim'd variable, it will cause a
compile error (which would prevent creating an accde) if Option Explicit is
set. It would not create a compile error if it's not set - but it probably
WOULD create an untrapped runtime error if the misnamed variable is ever
actually used!

--

John W. Vinson [MVP]

I saw your reply shortly after I left mine (and knew I wasn't losing my
mind). I take for granted that I compile all modules so often during
development (every couple lines sometimes... it just makes me feel good
and I forget that some people might not compile often, which would create a
case like this.

--
Jack Leach
www.tristatemachine.com

- "First, get your information. Then, you can distort it at your leisure."
- Mark Twain


"John W. Vinson" wrote:

> On Wed, 25 Feb 2009 16:14:00 -0800, dymondjack <dymondjack at hot mail dot
> com> wrote:
>
> >But, why would the code work during development, but not when transferred to
> >an accde? The need to remove the Explicit statement indicates problems with
> >variable naming, but for what reason would it not be caught in an accdb?
> >Maybe some sort of deeper db corruption?
>
> As I suggested in my reply, it may be that taking out Option Explicit is just
> papering over the problem. If there is an un-Dim'd variable, it will cause a
> compile error (which would prevent creating an accde) if Option Explicit is
> set. It would not create a compile error if it's not set - but it probably
> WOULD create an untrapped runtime error if the misnamed variable is ever
> actually used!
>
> --
>
> John W. Vinson [MVP]
>