By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,491 Members | 879 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,491 IT Pros & Developers. It's quick & easy.

If Hidden BackEnd BE not found then supress error revealing its location?

P: n/a
Hello

Split DB (FE & BE) Linked. FE compiled to MDE.

For security reasons, I have hidden the BackEnd. However, If the
network is down or the FE can't find the Backend, then an Access Error
reports exactly where the Backend is. This blows my attempt at hidding
the Backend file. I have tried to use the DIR() statement to look for
the BE in my FormOpen of my 1st form but it seems to be ignored.

Now do I detect ,right away, if the BackEnd is found so that I can
close down the app without it revealing where the BE file is hidden ?

Thanks Greg

Jul 14 '06 #1
Share this Question
Share on Google+
17 Replies


P: n/a
Show us the code for your DIR test.

(david)

<Ap******@gmail.comwrote in message
news:11*********************@35g2000cwc.googlegrou ps.com...
Hello

Split DB (FE & BE) Linked. FE compiled to MDE.

For security reasons, I have hidden the BackEnd. However, If the
network is down or the FE can't find the Backend, then an Access Error
reports exactly where the Backend is. This blows my attempt at hidding
the Backend file. I have tried to use the DIR() statement to look for
the BE in my FormOpen of my 1st form but it seems to be ignored.

Now do I detect ,right away, if the BackEnd is found so that I can
close down the app without it revealing where the BE file is hidden ?

Thanks Greg

Jul 14 '06 #2

P: n/a
Private Sub Form_Open(Cancel As Integer)
On Error GoTo Err_Handler 'I also shut off the
err_handler
MsgBox Len(Dir("c:\bfdx\nlf94p.mdb")) ' test for file

ERROR MESSAGE I'm receiving:
Could not find file 'c:\bfdx\nlf94p.ocx'.

I change the name of the Backend DB to deliberately test for the
missing file. Then the
code runs in the Form_Open and I recieve the error message. This Error
seems to occur before any code in the Form_Open executes. I know the
DIR statement works fine, because it properly tests for the file when
the file is renamed correctly.

david epsom dot com dot au wrote:
Show us the code for your DIR test.

(david)

<Ap******@gmail.comwrote in message
news:11*********************@35g2000cwc.googlegrou ps.com...
Hello

Split DB (FE & BE) Linked. FE compiled to MDE.

For security reasons, I have hidden the BackEnd. However, If the
network is down or the FE can't find the Backend, then an Access Error
reports exactly where the Backend is. This blows my attempt at hidding
the Backend file. I have tried to use the DIR() statement to look for
the BE in my FormOpen of my 1st form but it seems to be ignored.

Now do I detect ,right away, if the BackEnd is found so that I can
close down the app without it revealing where the BE file is hidden ?

Thanks Greg
Jul 14 '06 #3

P: n/a
You need to change the startup in your FE to check for the BE before opening
any forms or reports that access BE data.

<Ap******@gmail.comwrote in message
news:11*********************@35g2000cwc.googlegrou ps.com...
Hello

Split DB (FE & BE) Linked. FE compiled to MDE.

For security reasons, I have hidden the BackEnd. However, If the
network is down or the FE can't find the Backend, then an Access Error
reports exactly where the Backend is. This blows my attempt at hidding
the Backend file. I have tried to use the DIR() statement to look for
the BE in my FormOpen of my 1st form but it seems to be ignored.

Now do I detect ,right away, if the BackEnd is found so that I can
close down the app without it revealing where the BE file is hidden ?

Thanks Greg

Jul 14 '06 #4

P: n/a
Ron

I don't understand what you mean. I do not see any options in the
"Startup" allowing me to check for the BE. What I want to do is look
for the BE when the FE starts. I figured the place to do this is the
Form_Open of the FE. If I make this work, then I'll know if the BE
exists, or is gone. Then I can shut my app down. I DoNot want the FE
reporting that the BE is missing, and then displaying its path. For
security reasons, this will reveal my hidden backend. Not Good.

Thanks for Responding


paii, Ron wrote:
You need to change the startup in your FE to check for the BE before opening
any forms or reports that access BE data.

<Ap******@gmail.comwrote in message
news:11*********************@35g2000cwc.googlegrou ps.com...
Hello

Split DB (FE & BE) Linked. FE compiled to MDE.

For security reasons, I have hidden the BackEnd. However, If the
network is down or the FE can't find the Backend, then an Access Error
reports exactly where the Backend is. This blows my attempt at hidding
the Backend file. I have tried to use the DIR() statement to look for
the BE in my FormOpen of my 1st form but it seems to be ignored.

Now do I detect ,right away, if the BackEnd is found so that I can
close down the app without it revealing where the BE file is hidden ?

Thanks Greg
Jul 14 '06 #5

P: n/a
Ron

Sorry! I do understand what you mean!
However, in my startup forms record source property contains a table I
need to use.
Is there a way around this, like calling it form code. Or do I need to
use the autoexec macro, or load a phantom form before my startup form ?
Any suggestions?

Greg

Ap******@gmail.com wrote:
Ron

I don't understand what you mean. I do not see any options in the
"Startup" allowing me to check for the BE. What I want to do is look
for the BE when the FE starts. I figured the place to do this is the
Form_Open of the FE. If I make this work, then I'll know if the BE
exists, or is gone. Then I can shut my app down. I DoNot want the FE
reporting that the BE is missing, and then displaying its path. For
security reasons, this will reveal my hidden backend. Not Good.

Thanks for Responding


paii, Ron wrote:
You need to change the startup in your FE to check for the BE before opening
any forms or reports that access BE data.

<Ap******@gmail.comwrote in message
news:11*********************@35g2000cwc.googlegrou ps.com...
Hello
>
Split DB (FE & BE) Linked. FE compiled to MDE.
>
For security reasons, I have hidden the BackEnd. However, If the
network is down or the FE can't find the Backend, then an Access Error
reports exactly where the Backend is. This blows my attempt at hidding
the Backend file. I have tried to use the DIR() statement to look for
the BE in my FormOpen of my 1st form but it seems to be ignored.
>
Now do I detect ,right away, if the BackEnd is found so that I can
close down the app without it revealing where the BE file is hidden ?
>
Thanks Greg
>
Jul 14 '06 #6

P: n/a
You can use the autoexec macro, or create a new startup form that opens the
original after checking for the BE.

<Ap******@gmail.comwrote in message
news:11**********************@p79g2000cwp.googlegr oups.com...
Ron

Sorry! I do understand what you mean!
However, in my startup forms record source property contains a table I
need to use.
Is there a way around this, like calling it form code. Or do I need to
use the autoexec macro, or load a phantom form before my startup form ?
Any suggestions?

Greg

Ap******@gmail.com wrote:
Ron

I don't understand what you mean. I do not see any options in the
"Startup" allowing me to check for the BE. What I want to do is look
for the BE when the FE starts. I figured the place to do this is the
Form_Open of the FE. If I make this work, then I'll know if the BE
exists, or is gone. Then I can shut my app down. I DoNot want the FE
reporting that the BE is missing, and then displaying its path. For
security reasons, this will reveal my hidden backend. Not Good.

Thanks for Responding


paii, Ron wrote:
You need to change the startup in your FE to check for the BE before
opening
any forms or reports that access BE data.
>
<Ap******@gmail.comwrote in message
news:11*********************@35g2000cwc.googlegrou ps.com...
Hello

Split DB (FE & BE) Linked. FE compiled to MDE.

For security reasons, I have hidden the BackEnd. However, If the
network is down or the FE can't find the Backend, then an Access
Error
reports exactly where the Backend is. This blows my attempt at
hidding
the Backend file. I have tried to use the DIR() statement to look
for
the BE in my FormOpen of my 1st form but it seems to be ignored.

Now do I detect ,right away, if the BackEnd is found so that I can
close down the app without it revealing where the BE file is hidden
?

Thanks Greg

Jul 14 '06 #7

P: n/a
Ron

I used the autoexec. But, I still get the Error Message First! Then
the result from the AutoExec macro reports that the file is missing.
NotGood?
paii, Ron wrote:
You can use the autoexec macro, or create a new startup form that opens the
original after checking for the BE.

<Ap******@gmail.comwrote in message
news:11**********************@p79g2000cwp.googlegr oups.com...
Ron

Sorry! I do understand what you mean!
However, in my startup forms record source property contains a table I
need to use.
Is there a way around this, like calling it form code. Or do I need to
use the autoexec macro, or load a phantom form before my startup form ?
Any suggestions?

Greg

Ap******@gmail.com wrote:
Ron
>
I don't understand what you mean. I do not see any options in the
"Startup" allowing me to check for the BE. What I want to do is look
for the BE when the FE starts. I figured the place to do this is the
Form_Open of the FE. If I make this work, then I'll know if the BE
exists, or is gone. Then I can shut my app down. I DoNot want the FE
reporting that the BE is missing, and then displaying its path. For
security reasons, this will reveal my hidden backend. Not Good.
>
Thanks for Responding
>
>
>
>
paii, Ron wrote:
You need to change the startup in your FE to check for the BE before
opening
any forms or reports that access BE data.

<Ap******@gmail.comwrote in message
news:11*********************@35g2000cwc.googlegrou ps.com...
Hello
>
Split DB (FE & BE) Linked. FE compiled to MDE.
>
For security reasons, I have hidden the BackEnd. However, If the
network is down or the FE can't find the Backend, then an Access
Error
reports exactly where the Backend is. This blows my attempt at
hidding
the Backend file. I have tried to use the DIR() statement to look
for
the BE in my FormOpen of my 1st form but it seems to be ignored.
>
Now do I detect ,right away, if the BackEnd is found so that I can
close down the app without it revealing where the BE file is hidden
?
>
Thanks Greg
>
Jul 14 '06 #8

P: n/a
Ap******@gmail.com wrote:
Ron

I used the autoexec. But, I still get the Error Message First! Then
the result from the AutoExec macro reports that the file is missing.
NotGood?
You must run this test BEFORE any attempt is made by the app to hook into the
back end file. If you have a startup form specified in Options - Startup that
form will be loaded prior to the execution of the AuotExec macro.

The solution is to specify a form in startup that is hidden and unbound and that
has the sole purpose of running this test. If the file is found then that form
can close itself and open your "real" startup form.
--
Rick Brandt, Microsoft Access MVP
Email (as appropriate) to...
RBrandt at Hunter dot com
Jul 14 '06 #9

P: n/a
A new form would be my choice because the Dir() function can fail if the
path is invalid, which would crash your application if run from a macro.

"paii, Ron" <pa**@packairinc.comwrote in message
news:sc******************************@athenet.net. ..
You can use the autoexec macro, or create a new startup form that opens
the
original after checking for the BE.

<Ap******@gmail.comwrote in message
news:11**********************@p79g2000cwp.googlegr oups.com...
Ron

Sorry! I do understand what you mean!
However, in my startup forms record source property contains a table I
need to use.
Is there a way around this, like calling it form code. Or do I need to
use the autoexec macro, or load a phantom form before my startup form ?
Any suggestions?

Greg

Ap******@gmail.com wrote:
Ron
>
I don't understand what you mean. I do not see any options in the
"Startup" allowing me to check for the BE. What I want to do is look
for the BE when the FE starts. I figured the place to do this is the
Form_Open of the FE. If I make this work, then I'll know if the BE
exists, or is gone. Then I can shut my app down. I DoNot want the FE
reporting that the BE is missing, and then displaying its path. For
security reasons, this will reveal my hidden backend. Not Good.
>
Thanks for Responding
>
>
>
>
paii, Ron wrote:
You need to change the startup in your FE to check for the BE before
opening
any forms or reports that access BE data.

<Ap******@gmail.comwrote in message
news:11*********************@35g2000cwc.googlegrou ps.com...
Hello
>
Split DB (FE & BE) Linked. FE compiled to MDE.
>
For security reasons, I have hidden the BackEnd. However, If the
network is down or the FE can't find the Backend, then an Access
Error
reports exactly where the Backend is. This blows my attempt at
hidding
the Backend file. I have tried to use the DIR() statement to look
for
the BE in my FormOpen of my 1st form but it seems to be ignored.
>
Now do I detect ,right away, if the BackEnd is found so that I can
close down the app without it revealing where the BE file is
hidden
?
>
Thanks Greg
>


Jul 14 '06 #10

P: n/a
Solved The Problem!

I always thought the AutoExec macro was the first thing executed, but I
guess I was wrong. The Form specified in the Options->StartUp did
execute first. So, as suggested, I created a blank unbound form and
called it form there. In this form I check for the BE. If not found,
then I report the error and then close the database. If found, I open
my original Menu form, and close the blank form and I'm on my way.
Worked Great!

Private Sub Form_Open(Cancel As Integer) 'The OnOpen event of my
form "F-START"
If Len(Dir("MyFilePathandFile")) = 0 Then
MsgBox "BackEnd DataBase File Missing" & vbCrLf & vbCrLf _
& "The FileServer May Be Down?", vbExclamation,
"Monitoring Devices"
DoCmd.Quit
End If
'BE was found so continue
DoCmd.OpenForm "F-MENU" 'Run my menu form.
DoCmd.Close acForm, "F-START" 'Close the unbound form.
End Sub
ThankYou Rick and Ron!
Greg




paii, Ron wrote:
A new form would be my choice because the Dir() function can fail if the
path is invalid, which would crash your application if run from a macro.

"paii, Ron" <pa**@packairinc.comwrote in message
news:sc******************************@athenet.net. ..
You can use the autoexec macro, or create a new startup form that opens
the
original after checking for the BE.

<Ap******@gmail.comwrote in message
news:11**********************@p79g2000cwp.googlegr oups.com...
Ron
>
Sorry! I do understand what you mean!
However, in my startup forms record source property contains a table I
need to use.
Is there a way around this, like calling it form code. Or do I need to
use the autoexec macro, or load a phantom form before my startup form ?
Any suggestions?
>
Greg
>
>
>
Ap******@gmail.com wrote:
Ron

I don't understand what you mean. I do not see any options in the
"Startup" allowing me to check for the BE. What I want to do is look
for the BE when the FE starts. I figured the place to do this is the
Form_Open of the FE. If I make this work, then I'll know if the BE
exists, or is gone. Then I can shut my app down. I DoNot want the FE
reporting that the BE is missing, and then displaying its path. For
security reasons, this will reveal my hidden backend. Not Good.

Thanks for Responding




paii, Ron wrote:
You need to change the startup in your FE to check for the BE before
opening
any forms or reports that access BE data.
>
<Ap******@gmail.comwrote in message
news:11*********************@35g2000cwc.googlegrou ps.com...
Hello

Split DB (FE & BE) Linked. FE compiled to MDE.

For security reasons, I have hidden the BackEnd. However, If the
network is down or the FE can't find the Backend, then an Access
Error
reports exactly where the Backend is. This blows my attempt at
hidding
the Backend file. I have tried to use the DIR() statement to look
for
the BE in my FormOpen of my 1st form but it seems to be ignored.

Now do I detect ,right away, if the BackEnd is found so that I can
close down the app without it revealing where the BE file is
hidden
?

Thanks Greg

>
Jul 14 '06 #11

P: n/a
Ap******@gmail.com wrote:
Solved The Problem!

I always thought the AutoExec macro was the first thing executed, but
I guess I was wrong. The Form specified in the Options->StartUp did
execute first. [snip]
Yeah I just discovered that myself several months ago. Seems like the AutoExec
should come first to me, but...

--
Rick Brandt, Microsoft Access MVP
Email (as appropriate) to...
RBrandt at Hunter dot com
Jul 14 '06 #12

P: n/a
"Rick Brandt" <ri*********@hotmail.comwrote in
news:Sg*******************@newssvr14.news.prodigy. com:
Ap******@gmail.com wrote:
>Solved The Problem!

I always thought the AutoExec macro was the first thing executed,
but I guess I was wrong. The Form specified in the
Options->StartUp did execute first. [snip]

Yeah I just discovered that myself several months ago. Seems like
the AutoExec should come first to me, but...
why would anyone use both an Autoexec and a startup form?

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Jul 15 '06 #13

P: n/a
David W. Fenton wrote:
"Rick Brandt" <ri*********@hotmail.comwrote in
news:Sg*******************@newssvr14.news.prodigy. com:
Ap******@gmail.com wrote:
Solved The Problem!
>
I always thought the AutoExec macro was the first thing executed,
but I guess I was wrong. The Form specified in the
Options->StartUp did execute first. [snip]
Yeah I just discovered that myself several months ago. Seems like
the AutoExec should come first to me, but...

why would anyone use both an Autoexec and a startup form?
One would never "need" to, but I had a utility app that used AutoExec that I
later added a startup form to. Somewhat later I discovered a bug caused by the
fact that the startup form's open code was running before the AutoExec call
which was not what I expected.

--
Rick Brandt, Microsoft Access MVP
Email (as appropriate) to...
RBrandt at Hunter dot com
Jul 15 '06 #14

P: n/a
David W. Fenton wrote:
"Rick Brandt" <ri*********@hotmail.comwrote in
news:Sg*******************@newssvr14.news.prodigy. com:
Ap******@gmail.com wrote:
Solved The Problem!

I always thought the AutoExec macro was the first thing executed,
but I guess I was wrong. The Form specified in the
Options->StartUp did execute first. [snip]
Yeah I just discovered that myself several months ago. Seems like
the AutoExec should come first to me, but...

why would anyone use both an Autoexec and a startup form?

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
In my early attempts, modification of Access 2007's Ribbon must be
initiated by firing an autoexec macro; a start up form seems too late.
So this is the first time I have used an autoexec macro. But I may
still want a visible startup form to allow or require the user to do
something.
Of course, this is a pretty obscure circumstance and it's entirely
possible that someone will point out a way to modify the ribbon without
using an autoexec macro.

Jul 15 '06 #15

P: n/a
Lyle Fairfield wrote:
In my early attempts, modification of Access 2007's Ribbon must be
initiated by firing an autoexec macro; a start up form seems too late.
[snip]

Interesting. Has the order been reversed in 2007 so that the AutoExec now fires
before the startup form or is there just some requirement that ribbon mods must
be done via macro (yuck)?

--
Rick Brandt, Microsoft Access MVP
Email (as appropriate) to...
RBrandt at Hunter dot com
Jul 15 '06 #16

P: n/a
Rick Brandt wrote:
Lyle Fairfield wrote:
In my early attempts, modification of Access 2007's Ribbon must be
initiated by firing an autoexec macro; a start up form seems too late.
[snip]

Interesting. Has the order been reversed in 2007 so that the AutoExec now fires
before the startup form or is there just some requirement that ribbon mods must
be done via macro (yuck)?

--
Rick Brandt, Microsoft Access MVP
Email (as appropriate) to...
RBrandt at Hunter dot com
http://blogs.msdn.com/access/archive...13/664757.aspx

has some information about how to customize the ribbon. I'm guessing
that the VBA callback functions have to be in a Macro.

Maybe use VBA as an XML editor :-).

James A. Fortune
CD********@FortuneJames.com

Jul 16 '06 #17

P: n/a
Rick Brandt wrote:
Lyle Fairfield wrote:
In my early attempts, modification of Access 2007's Ribbon must be
initiated by firing an autoexec macro; a start up form seems too late.
[snip]

Interesting. Has the order been reversed in 2007 so that the AutoExec now fires
before the startup form or is there just some requirement that ribbon mods must
be done via macro (yuck)?

--
Rick Brandt, Microsoft Access MVP
Email (as appropriate) to...
RBrandt at Hunter dot com
I think I have mispoken. TTBOMK one uses the AutoExec Macro to run the
code that modifies the Ribbon .

An example that does nothing but hide the ribbon is:

The AutoExec Macro is

Command:RunCode
Argument: temp()

The Code is
Public Function temp()
Dim r As DAO.Recordset
Set r = DBEngine(0)(0).OpenRecordset("Table1")
Application.LoadCustomUI r.Collect(1), r.Collect(2)
Set r = Nothing
End Function

In Table 1 is one record with Fields:

ID:1
RibbonName:HideRibbon
RibbonXML:
<customUI xmlns="http://schemas.microsoft.com/office/2006/01/customui">

<ribbon startFromScratch="true">

</ribbon>

</customUI>

r.Collect(1) then is HideRibbon
and
r.Collect(2) is
<customUI xmlns="http://schemas.microsoft.com/office/2006/01/customui">
<ribbon startFromScratch="true">
</ribbon>
</customUI>

As for a start up form, my GUESS is the one will open up one's start up
form by doing a

DoCmd.OpenForm at the end of the code called by the macro.

Sounds clumsy ...yes?

Jul 16 '06 #18

This discussion thread is closed

Replies have been disabled for this discussion.