Mr. Kallal & Mr. Fenton: What did I do wrong?

Thank you, Tom.

In that case I think I can say: I always create my own unbound Switchboard
so that I'm sure I don't have to connect to any BE MDB when I open the
Switchboard (main form).

Vlado

"Tom Wickerath" AOS168b AT comcast DOT net pÃ*Å¡e v diskusnÃ*m pÅ™Ã*spÄ›vku
...
Hi VladimÃ*r,

Yes, I think so.


Tom Wickerath
Microsoft Access MVP
https://mvp.support.microsoft.com/profile/Tom
http://www.access.qbuilt.com/html/ex...tributors.html
__________________________________________

"VladimÃ*r Cvajniga" wrote:

In English, is Switchboard the same as the Dashboard (in terms of MS
Access)?

Vlado

Hi Vlado,

Okay, so when you open your front-end application normally (ie. *not*
holding down the shift key), do you see a locking database file (*.ldb)
created for the back-end .mdb file? If so, you have a persistent connection.
If not, then you don't.

Note: Best to test by having the BE on your local hard drive, or at a time
when you know that no other users have the database open.


Tom Wickerath
Microsoft Access MVP
https://mvp.support.microsoft.com/profile/Tom
http://www.access.qbuilt.com/html/ex...tributors.html
__________________________________________

"VladimÃ*r Cvajniga" wrote:

Thank you, Tom.

In that case I think I can say: I always create my own unbound Switchboard
so that I'm sure I don't have to connect to any BE MDB when I open the
Switchboard (main form).

Vlado

Tom Wickerath AOS168b AT comcast DOT net wrote in
news
But what if someone has the front end open, you add the menu item
to the Switchboard, and they go to the reports menu on it.
They'll see the report before they've got it in their front end.

You'd trap for the error and present a customized message, such as
"This report will be available shortly."

And so you have to add a workaround which isn't necessary if you
keep the Switchboard table in the front end.

I think it's obvious that the UI to give access to the
application's functions is by definition a UI object and all its
components should be kept in synch with the front end.

I'm inclined to agree with you here, given that the VBA code
behind my unbound switchboard forms is in the front-end too (which
is the only place it really could be).

So you're arguing just for the fun of it? OK!

What do you gain by putting the table in the back end? Nothing --
if it's ...

I disagree. You do gain an automatic persistent connection,
without having to do anything else, so there *is* something to be
gained. Sure, you may have to work around some issues, like
trapping for an error in the event a report is not yet available,
but that's certainly not insurmountable.

If you're going to have to write code to trap for putting the table
in the wrong place, then why not write code to create a persistent
connection with a table that *belongs* in the back end?

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

Tom Wickerath AOS168b AT comcast DOT net wrote in
:

What can possibly be gained in terms of Switchboard functionality
by putting the Switchboard table in the back end?

What I've already mentioned a few times: a persistent connection
without the need to do anything else.

But it causes you to have to do *other* things, like making sure you
don't add the value in the production back end Switchboard table
until you have the front end ready to distribute, and you have to
write code for the case where somebody attempts to open the report
before they have the new front end.

As opposed to simply writing a couple of lines of code that create
the persistent connection.

Really, isn't:

Dim dbBackEnd As DAO.Database
Dim strBackEnd as String

strBackEnd = Mid(CurrentDb.TableDefs("MyTable").Connect, 11)
Set dbBackEnd = DBEngine.OpenDatabase(strBackEnd)

much easier than error catching code for the report and the planning
needed to worry about coordinating distributing the new front end
with entering the new data in the back end Switchboard table?

And besides, your persistent connection could disappear if the user
closes the Switchboard form. So, you'd have to write code that
prevents the Switchboard from being closed except by the EXIT button
for the application, so you've added still more code to work around
problems created by using the Switchboard for something other than
its intended purpose.

But it also introduces problems because of a period of latency
between adding the items to the table and rolling out the front
end.

In my case, probalby not. I tend to be a late night owl, so in my
case, by the time I'm making that new FE available (and updating a
linked SI table [if I used one]) all other employees have long
since gone home. In any case, just trap for any errors in the FE,
and present a customized error message, such as "This report will
be available shortly". No big deal really.

I think it's silly to write error trapping code for something that
doesn't need it. You're using the Switchboard table for a different
purpose (maintaining the persistent connection) than for what it is
designed to do, and that causes you to put it in a place that leads
to workarounds to fix the problems caused by moving it to the back
end.

It's a very Microsoft approach, to make an incorrect decision on the
front end (e.g., the SDI in Office) and then to create an elaborate
workaround to fix the problem created by the bad decision in the
first place (i.e., change your OS to group the multiplying
application windows in the TaskBar).

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

But it causes you to have to do *other* things, like making sure you
don't add the value in the production back end Switchboard table
until you have the front end ready to distribute, ...

Is that *really* so difficult? C'mon.

and you have to
write code for the case where somebody attempts to open the report
before they have the new front end.

Only if you 1.) must be able to update the app. during normal business hours
and 2.) want to prevent any possible errors. Both of these are certainly
laudable goals, and, as I've already indicated, *if* I used a switchboard
with a bound table design [which I don't], I probably would just leave it in
the FE. The whole point of this {rather fruitless} discussion is to simply
offer a counterpoint to the opinion that one *must* put the Switchboard Items
table in the FE.

Really, isn't:
snip
much easier than error catching code for the report and the planning
needed to worry about coordinating distributing the new front end
with entering the new data in the back end Switchboard table?

It might be easier, but I wouldn't necessarily advice doing so, if you want
to ensure that each user has true record-level locking. You're much easier
code just resulted in page-level locking.

PRB: Jet 4.0 Row-Level Locking Is Not Available with DAO 3.60
http://support.microsoft.com/?id=306435

The ToolsOptions... | Advanced tab setting "Open databases using
record-level locking" is a request, not a demand.

And besides, your persistent connection could disappear if the user
closes the Switchboard form.

My users aren't allowed to close the switchboard form without closing the
application.

So, you'd have to write code that
prevents the Switchboard from being closed except by the EXIT button
for the application, so you've added still more code...

Yeah, the only code that I really need to write is DoCmd.Quit on the EXIT
button, after disabling the Control Box for the form. By the way, I also only
distribute in the compiled .mde form, with shift key disabled. Certainly it
is easy enough for a knowledgeable person to re-enable the shift key, but I
have not found this to even be an issue. For one thing, most of my users
wouldn't know where to find the FE application. It is in the
hidden-by-default folder:

C:\Documents and Settings\NTUserID\Application Data\AppName\AppName.mde

(That's a nice benefit of using the AutoFE Updater, by the way. It's very
easy to create this path if it is not already present, and copy the FE app.
to this folder, using Tony's tool).



Tom Wickerath
Microsoft Access MVP
https://mvp.support.microsoft.com/profile/Tom
http://www.access.qbuilt.com/html/ex...tributors.html
__________________________________________

"David W. Fenton" wrote:

Tom Wickerath AOS168b AT comcast DOT net wrote in
:

What can possibly be gained in terms of Switchboard functionality
by putting the Switchboard table in the back end?

What I've already mentioned a few times: a persistent connection
without the need to do anything else.

But it causes you to have to do *other* things, like making sure you
don't add the value in the production back end Switchboard table
until you have the front end ready to distribute, and you have to
write code for the case where somebody attempts to open the report
before they have the new front end.

As opposed to simply writing a couple of lines of code that create
the persistent connection.

Really, isn't:

Dim dbBackEnd As DAO.Database
Dim strBackEnd as String

strBackEnd = Mid(CurrentDb.TableDefs("MyTable").Connect, 11)
Set dbBackEnd = DBEngine.OpenDatabase(strBackEnd)

much easier than error catching code for the report and the planning
needed to worry about coordinating distributing the new front end
with entering the new data in the back end Switchboard table?

And besides, your persistent connection could disappear if the user
closes the Switchboard form. So, you'd have to write code that
prevents the Switchboard from being closed except by the EXIT button
for the application, so you've added still more code to work around
problems created by using the Switchboard for something other than
its intended purpose.

But it also introduces problems because of a period of latency
between adding the items to the table and rolling out the front
end.

In my case, probalby not. I tend to be a late night owl, so in my
case, by the time I'm making that new FE available (and updating a
linked SI table [if I used one]) all other employees have long
since gone home. In any case, just trap for any errors in the FE,
and present a customized error message, such as "This report will
be available shortly". No big deal really.

I think it's silly to write error trapping code for something that
doesn't need it. You're using the Switchboard table for a different
purpose (maintaining the persistent connection) than for what it is
designed to do, and that causes you to put it in a place that leads
to workarounds to fix the problems caused by moving it to the back
end.

It's a very Microsoft approach, to make an incorrect decision on the
front end (e.g., the SDI in Office) and then to create an elaborate
workaround to fix the problem created by the bad decision in the
first place (i.e., change your OS to group the multiplying
application windows in the TaskBar).

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

Tom Wickerath AOS168b AT comcast DOT net wrote in
:

But it causes you to have to do *other* things, like making sure
you don't add the value in the production back end Switchboard
table until you have the front end ready to distribute, ...

Is that *really* so difficult? C'mon.

It's one more thing that can go wrong. Just yesterday I accidentally
killed a live file on a website because I forgot to rename the work
copy before uploading it. Is that so difficult to get right? Not at
all! But I'm human and I make mistakes. Why design your app in a
fashion that increases the number of things on which you can make
mistakes?

and you have to
write code for the case where somebody attempts to open the
report before they have the new front end.

Only if you 1.) must be able to update the app. during normal
business hours and 2.) want to prevent any possible errors. Both
of these are certainly laudable goals, and, as I've already
indicated, *if* I used a switchboard with a bound table design
[which I don't], I probably would just leave it in the FE. The
whole point of this {rather fruitless} discussion is to simply
offer a counterpoint to the opinion that one *must* put the
Switchboard Items table in the FE.

I don't think you've made a good case for it.

Really, isn't:
snip
much easier than error catching code for the report and the
planning needed to worry about coordinating distributing the new
front end with entering the new data in the back end Switchboard
table?

It might be easier, but I wouldn't necessarily advice doing so, if
you want to ensure that each user has true record-level locking.
You're much easier code just resulted in page-level locking.

PRB: Jet 4.0 Row-Level Locking Is Not Available with DAO 3.60
http://support.microsoft.com/?id=306435

The ToolsOptions... | Advanced tab setting "Open databases using
record-level locking" is a request, not a demand.

I didn't know that. Apparently, nobody recommending the persistent
connection in code knows it, either.

Of course, I don't give a rat's ass about row-level locking, myself.
I don't use it and don't think it really works. But maybe that's
because I've always been using methods that prevent it.

And besides, your persistent connection could disappear if the
user closes the Switchboard form.

My users aren't allowed to close the switchboard form without
closing the application.

So, you'd have to write code that
prevents the Switchboard from being closed except by the EXIT
button for the application, so you've added still more code...

Yeah, the only code that I really need to write is DoCmd.Quit on
the EXIT button, after disabling the Control Box for the form.

Do you also trap for Ctrl-F4? To really prevent it from closing, you
have to set a flag in your real exit code that is checked in the
OnClose event. If your real exit code hasn't run, the flag is not
set, and you cancel the form's close. That's the only way to really
prevent a form from being closed.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

"Tom Wickerath" AOS168b AT comcast DOT net wrote in message
...
But it causes you to have to do *other* things, like making sure you
don't add the value in the production back end Switchboard table
until you have the front end ready to distribute, ...

Is that *really* so difficult? C'mon.

and you have to
write code for the case where somebody attempts to open the report
before they have the new front end.

Only if you 1.) must be able to update the app. during normal business
hours
and 2.) want to prevent any possible errors. Both of these are certainly
laudable goals, and, as I've already indicated, *if* I used a switchboard
with a bound table design [which I don't], I probably would just leave it
in
the FE. The whole point of this {rather fruitless} discussion is to simply
offer a counterpoint to the opinion that one *must* put the Switchboard
Items
table in the FE.

Really, isn't:
snip
much easier than error catching code for the report and the planning
needed to worry about coordinating distributing the new front end
with entering the new data in the back end Switchboard table?

It might be easier, but I wouldn't necessarily advice doing so, if you
want
to ensure that each user has true record-level locking. You're much easier
code just resulted in page-level locking.

PRB: Jet 4.0 Row-Level Locking Is Not Available with DAO 3.60
http://support.microsoft.com/?id=306435

The ToolsOptions... | Advanced tab setting "Open databases using
record-level locking" is a request, not a demand.

And besides, your persistent connection could disappear if the user
closes the Switchboard form.

My users aren't allowed to close the switchboard form without closing the
application.

So, you'd have to write code that
prevents the Switchboard from being closed except by the EXIT button
for the application, so you've added still more code...

Yeah, the only code that I really need to write is DoCmd.Quit on the EXIT
button, after disabling the Control Box for the form. By the way, I also
only
distribute in the compiled .mde form, with shift key disabled. Certainly
it
is easy enough for a knowledgeable person to re-enable the shift key, but
I
have not found this to even be an issue. For one thing, most of my users
wouldn't know where to find the FE application. It is in the
hidden-by-default folder:

C:\Documents and Settings\NTUserID\Application Data\AppName\AppName.mde

(That's a nice benefit of using the AutoFE Updater, by the way. It's very
easy to create this path if it is not already present, and copy the FE
app.
to this folder, using Tony's tool).



Tom Wickerath
Microsoft Access MVP
https://mvp.support.microsoft.com/profile/Tom
http://www.access.qbuilt.com/html/ex...tributors.html
__________________________________________

"David W. Fenton" wrote:

Tom Wickerath AOS168b AT comcast DOT net wrote in
:

What can possibly be gained in terms of Switchboard functionality
by putting the Switchboard table in the back end?

What I've already mentioned a few times: a persistent connection
without the need to do anything else.

But it causes you to have to do *other* things, like making sure you
don't add the value in the production back end Switchboard table
until you have the front end ready to distribute, and you have to
write code for the case where somebody attempts to open the report
before they have the new front end.

As opposed to simply writing a couple of lines of code that create
the persistent connection.

Really, isn't:

Dim dbBackEnd As DAO.Database
Dim strBackEnd as String

strBackEnd = Mid(CurrentDb.TableDefs("MyTable").Connect, 11)
Set dbBackEnd = DBEngine.OpenDatabase(strBackEnd)

much easier than error catching code for the report and the planning
needed to worry about coordinating distributing the new front end
with entering the new data in the back end Switchboard table?

And besides, your persistent connection could disappear if the user
closes the Switchboard form. So, you'd have to write code that
prevents the Switchboard from being closed except by the EXIT button
for the application, so you've added still more code to work around
problems created by using the Switchboard for something other than
its intended purpose.

But it also introduces problems because of a period of latency
between adding the items to the table and rolling out the front
end.

In my case, probalby not. I tend to be a late night owl, so in my
case, by the time I'm making that new FE available (and updating a
linked SI table [if I used one]) all other employees have long
since gone home. In any case, just trap for any errors in the FE,
and present a customized error message, such as "This report will
be available shortly". No big deal really.

I think it's silly to write error trapping code for something that
doesn't need it. You're using the Switchboard table for a different
purpose (maintaining the persistent connection) than for what it is
designed to do, and that causes you to put it in a place that leads
to workarounds to fix the problems caused by moving it to the back
end.

It's a very Microsoft approach, to make an incorrect decision on the
front end (e.g., the SDI in Office) and then to create an elaborate
workaround to fix the problem created by the bad decision in the
first place (i.e., change your OS to group the multiplying
application windows in the TaskBar).

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

Hello,

I'd like to thank all for their comments & help. I have finished simple
tests on my (very slow) home P2P.
BE MDB was A97 MDB.

1) In my case, persistent connection ALWAYS slows down performance. Could it
be due to Czech version af Access? Therefore I will not apply persistent
connection in any of my A97 projects.
2) Registry settings (http://support.microsoft.com/kb/150384/) significantly
speed up performance if BE MDB is already open.
3) In the whole, David Fenton's method (global db variable) seems to work as
expected but, in my case, it slows down performance as well. I'd recommend
some tests on Jet 4 and non-P2P network.

Vlado
=============================================
Important increase of performance are marked with an asterisk (*).

P2P:
- notebook Acer TravelMate 223X
- Windows XP Professional CZ SP2
- 256 MB RAM
- 10MBit LAN card
- MS Office 97 Professional CZ SP2

- desktop PC (noname):
- Windows XP Professional CZ SP2
- P4, 786 MB RAM
- 100MBit LAN card
- MS Office 2002 Professional CZ SP2
———————————————————————————————————————————————
- notebook Acer TravelMate 223X
- main database: KES_data.mdb
- table Karta: 36 records

c:\Dokumenty\_Moje
projekty\Kes\Databaze2002\97\CvicnaDatabazeZS\KES_ data.mdb
on desktop mapped as Z:\Databaze2002\97\CvicnaDatabazeZS\KES_data.mdb
———————————————————————————————————————————————
desktop:
db1.mdb with connection to KES_data.mdb on notebook

without persistent connection:
desktop tests, see Public Function test:
9,203125 seconds
9,203125 seconds
9,203125 seconds

persistent connection created on notebook:
db1.mdb with connection to KES_data.mdb (db1 open in Access 97):
desktop tests, see Public Function test:
- open table VZDY (1 record):
40,21875 seconds
40,14063 seconds
40,48438 seconds

- open table VZDYtmp (0 records):
40,32813 seconds
40,20313 seconds
40,23438 seconds

persistent connection created on notebook:
db variable (no table open), see modPersistent.fncPersistentOpen
40,21875 seconds
40,14063 seconds
40,25 seconds
—————————————————————————————————————————
desktop:
desktop project KES.mdb (A97 project converted to A2002): 44.3MB
connected to Z:\Databaze2002\97\CvicnaDatabazeZS\KES_data.mdb
desktop project startup
without persistent connection:
35,7 seconds
35,8 seconds
34,7 seconds

desktop project startup
connected to Z:\Databaze2002\97\CvicnaDatabazeZS\KES_data.mdb
persistent connection created on notebook:
db variable, see modPersistent.fncPersistentOpen
2 minutes 34,7 seconds
2 minutes 33,0 seconds
2 minutes 32,4 seconds
—————————————————————————————————————————
notebook, from db1.mdb, no persistent connection:
0,151001 seconds
0,1500244 seconds
0,1500244 seconds
—————————————————————————————————————————
—————————————————————————————————————————
—————————————————————————————————————————
After changes in notebook's registry.
See http://support.microsoft.com/kb/150384/

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Servic es\LanmanServer\Parameters

Value Name: SharingViolationDelay
Data Type: REG_DWORD
Data: 0 (Default: 200)

Value Name: SharingViolationRetries
Data Type: REG_DWORD
Data: 0 (Default: 5)
.................................................. ...................................
desktop:
db1.mdb with connection to KES_data.mdb on notebook

without persistent connection:
desktop tests, see Public Function test:
9,84375 seconds
9,90625 seconds
9,78125 seconds

persistent connection created on notebook:
db1.mdb with connection to KES_data.mdb (db1 open in Access 97):
desktop tests, see Public Function test:
- open table VZDY (1 record):
21,04736 seconds *
21,09424 seconds *
21,18701 seconds *

- open table VZDYtmp (0 records):
21,26514 seconds *
21,20264 seconds *
21,39063 seconds *

persistent connection created on notebook:
db variable (no table open), see modPersistent.fncPersistentOpen
21,25 seconds *
21,14063 seconds *
21,0 seconds *
—————————————————————————————————————————
desktop:
desktop project KES.mdb (A97 project converted to A2002): 44.3MB
connected to Z:\Databaze2002\97\CvicnaDatabazeZS\KES_data.mdb
desktop project startup
without persistent connection:
34,6 seconds
35,2 seconds
35,7 seconds

desktop project startup
connected to Z:\Databaze2002\97\CvicnaDatabazeZS\KES_data.mdb
persistent connection created on notebook:
db variable, see modPersistent.fncPersistentOpen
1 minute 11,1 seconds *
1 minute 12,7 seconds *
1 minute 10,1 seconds *
—————————————————————————————————————————
notebook, from db1.mdb, no persistent connection:
0,1508789 seconds
0,1401367 seconds
0,1503906 seconds
—————————————————————————————————————————
—————————————————————————————————————————
—————————————————————————————————————————
Note:
All timings apply to "cached" data (ie. 2nd, 3rd, 4th, ..., data access).
—————————————————————————————————————————
Public Function test()
Dim PauseTime, Start, Finish, TotalTime, i, s

Start = Timer

For i = 1 To 10
Debug.Print DCount("*", "Karta")
DoEvents
Next i

Finish = Timer
TotalTime = Finish - Start
s = TotalTime & " seconds"
Debug.Print s
MsgBox "Total time: " & s

End Function
—————————————————————————————————————————
modPersistent
Option Compare Database
Option Explicit

Public db As Database

Public Function fncPersistentOpen()
Set db = DBEngine.OpenDatabase("c:\Dokumenty\_Moje
projekty\Kes\Databaze2002\97\CvicnaDatabazeZS\KES_ data.mdb")
End Function

Public Function fncPersistentClose()
db.Close
Set db = Nothing
End Function

Of course, I don't give a rat's ass about row-level locking, myself.
I don't use it and don't think it really works.

Interesting that you would make this statement, given your earlier statement
in the Persistanct connections thread to Tom Ellison, in which you wrote:

"On the contrary, it can be *very* useful in reducing concurrency. A
random Autonumber means that the data ends up randomly distributed,
so that updates are not as likely to collide on the same data page."

(Note: "it" being a reference to a surrogate key versus a natural key).

So, you indicate an advantage of using a surrogate key helps to avoid
collisions on the same data page, yet you don't give a R.A. about row level
locking?


But maybe that's because I've always been using methods that prevent it.

I suspect so.


Tom Wickerath
Microsoft Access MVP
https://mvp.support.microsoft.com/profile/Tom
http://www.access.qbuilt.com/html/ex...tributors.html
__________________________________________

"David W. Fenton" wrote:

Tom Wickerath AOS168b AT comcast DOT net wrote in
:

But it causes you to have to do *other* things, like making sure
you don't add the value in the production back end Switchboard
table until you have the front end ready to distribute, ...

Is that *really* so difficult? C'mon.

It's one more thing that can go wrong. Just yesterday I accidentally
killed a live file on a website because I forgot to rename the work
copy before uploading it. Is that so difficult to get right? Not at
all! But I'm human and I make mistakes. Why design your app in a
fashion that increases the number of things on which you can make
mistakes?

and you have to
write code for the case where somebody attempts to open the
report before they have the new front end.

Only if you 1.) must be able to update the app. during normal
business hours and 2.) want to prevent any possible errors. Both
of these are certainly laudable goals, and, as I've already
indicated, *if* I used a switchboard with a bound table design
[which I don't], I probably would just leave it in the FE. The
whole point of this {rather fruitless} discussion is to simply
offer a counterpoint to the opinion that one *must* put the
Switchboard Items table in the FE.

I don't think you've made a good case for it.

Really, isn't:
snip
much easier than error catching code for the report and the
planning needed to worry about coordinating distributing the new
front end with entering the new data in the back end Switchboard
table?

It might be easier, but I wouldn't necessarily advice doing so, if
you want to ensure that each user has true record-level locking.
You're much easier code just resulted in page-level locking.

PRB: Jet 4.0 Row-Level Locking Is Not Available with DAO 3.60
http://support.microsoft.com/?id=306435

The ToolsOptions... | Advanced tab setting "Open databases using
record-level locking" is a request, not a demand.

I didn't know that. Apparently, nobody recommending the persistent
connection in code knows it, either.

Of course, I don't give a rat's ass about row-level locking, myself.
I don't use it and don't think it really works. But maybe that's
because I've always been using methods that prevent it.

And besides, your persistent connection could disappear if the
user closes the Switchboard form.

My users aren't allowed to close the switchboard form without
closing the application.

So, you'd have to write code that
prevents the Switchboard from being closed except by the EXIT
button for the application, so you've added still more code...

Yeah, the only code that I really need to write is DoCmd.Quit on
the EXIT button, after disabling the Control Box for the form.

Do you also trap for Ctrl-F4? To really prevent it from closing, you
have to set a flag in your real exit code that is checked in the
OnClose event. If your real exit code hasn't run, the flag is not
set, and you cancel the form's close. That's the only way to really
prevent a form from being closed.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

Do you also trap for Ctrl-F4?

Nope. I suppose if a user tries to close my switchboard doing this, they'll
end up with Access still running, but a blank window. They won't be able to
display the database window using F11, since I remove the option that allows
the use of special keys, and I disable the shift key trick. (Yes, I know, a
knowledgeable user can always re-enable the shift key).

I suppose I could add an Autokeys macro to re-direct this key sequence, but
so far, no one has ever mentioned it being a problem.


Tom Wickerath
Microsoft Access MVP
https://mvp.support.microsoft.com/profile/Tom
http://www.access.qbuilt.com/html/ex...tributors.html
__________________________________________

"David W. Fenton" wrote:

snip

Do you also trap for Ctrl-F4? To really prevent it from closing, you
have to set a flag in your real exit code that is checked in the
OnClose event. If your real exit code hasn't run, the flag is not
set, and you cancel the form's close. That's the only way to really
prevent a form from being closed.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/