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

[ApexData]

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

[ApexData]

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(Cance l As Integer) 'The OnOpen event of my
form "F-START"
If Len(Dir("MyFile PathandFile")) = 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**@packairin c.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.goo glegroups.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******** *************@3 5g2000cwc.googl egroups.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

>

[Rick Brandt]

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

[David W. Fenton]

"Rick Brandt" <ri*********@ho tmail.comwrote in
news:Sg******** ***********@new ssvr14.news.pro digy.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/

[Rick Brandt]

David W. Fenton wrote:

"Rick Brandt" <ri*********@ho tmail.comwrote in
news:Sg******** ***********@new ssvr14.news.pro digy.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

[Lyle Fairfield]

David W. Fenton wrote:

"Rick Brandt" <ri*********@ho tmail.comwrote in
news:Sg******** ***********@new ssvr14.news.pro digy.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.

[Rick Brandt]

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

[CDMAPoster]

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********@Fort uneJames.com

[Lyle Fairfield]

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.Loa dCustomUI r.Collect(1), r.Collect(2)
Set r = Nothing
End Function

In Table 1 is one record with Fields:

ID:1
RibbonName:Hide Ribbon
RibbonXML:
<customUI xmlns="http://schemas.microso ft.com/office/2006/01/customui">

<ribbon startFromScratc h="true">

</ribbon>

</customUI>

r.Collect(1) then is HideRibbon
and
r.Collect(2) is
<customUI xmlns="http://schemas.microso ft.com/office/2006/01/customui">
<ribbon startFromScratc h="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?