shorten time to attempt to connect to back end

[Mike MacSween]

Some of my users are getting 'Disk or Network Errors'. I've raised it with
the network admins, they're looking into it.

In the meantime...

My 'standard' error handlers logs errors to a table in the shared backend.
Nice. Unless the error is cause by the above. The error handler in the
logging procedure doesn't attempt to log errors there, as the most likely
cause of an error in the logging procedure is loss of connectivity. But this
still seems to be a show stopper.

So somewhere in this I'd like to test whether connectivity has been lost.
I'm trying this:

Public Function CheckLinks() As Boolean
' Returns True if links are OK.
Dim rst As DAO.Recordset
On Error Resume Next
Set rst = CurrentDb().OpenRecordset("zstLogErr")
CheckLinks = (Err.Number = 0) 'If no error, return True.
rst.Close
End Function

Which seems to work. That is to say if I unplug the network cable (which is
the only way I can think of duplicating the test) it returns false. After
about 25 seconds. I'd like to make that instant. How to?

OK, found the answer. Seems to be the OLE/DDE setting. But is there an
optimum setting for that? The default is 30 seconds. In fact, if the
disk/network error is caused by a slightly intermittent network, would it be
better to make that a lot _longer_?

Or has anybody got a VBA version of ping?

Cheers, Mike MacSween

[Tom van Stiphout]

On Wed, 14 Sep 2005 08:33:31 +0100, "Mike MacSween"
<mi******************@btinternet.com> wrote:

Testing every time seems so brute-force.

Assuming you have outfit your app with error handlers throughout, and
a central error handling function, in that function you can check for
certain error values that would indicate loss of back-end.

Btw, if you have intermittent loss of network, then you will likely
have backend corruption waiting to happen (I'm assuming MDB backend).
With Win2000 and up, you can display the network icon in the taskbar,
and it will popup a balloon when it reconnects. If users are reporting
that, it's time to have the hardware guys take a serious look at that.

-Tom.

Some of my users are getting 'Disk or Network Errors'. I've raised it with
the network admins, they're looking into it.

In the meantime...

My 'standard' error handlers logs errors to a table in the shared backend.
Nice. Unless the error is cause by the above. The error handler in the
logging procedure doesn't attempt to log errors there, as the most likely
cause of an error in the logging procedure is loss of connectivity. But this
still seems to be a show stopper.

So somewhere in this I'd like to test whether connectivity has been lost.
I'm trying this:

Public Function CheckLinks() As Boolean
' Returns True if links are OK.
Dim rst As DAO.Recordset
On Error Resume Next
Set rst = CurrentDb().OpenRecordset("zstLogErr")
CheckLinks = (Err.Number = 0) 'If no error, return True.
rst.Close
End Function

Which seems to work. That is to say if I unplug the network cable (which is
the only way I can think of duplicating the test) it returns false. After
about 25 seconds. I'd like to make that instant. How to?

OK, found the answer. Seems to be the OLE/DDE setting. But is there an
optimum setting for that? The default is 30 seconds. In fact, if the
disk/network error is caused by a slightly intermittent network, would it be
better to make that a lot _longer_?

Or has anybody got a VBA version of ping?

Cheers, Mike MacSween

[Mike MacSween]

"Tom van Stiphout" <no*************@cox.net> wrote in message
news:c8********************************@4ax.com...

On Wed, 14 Sep 2005 08:33:31 +0100, "Mike MacSween"
<mi******************@btinternet.com> wrote:

Testing every time seems so brute-force.
Yes, I'm just putting this in the central error handler. In fact in the
function that attempts to write to the error log.
Assuming you have outfit your app with error handlers throughout, and
a central error handling function, in that function you can check for
certain error values that would indicate loss of back-end.
Tried it with the above code, which really slows things down, as Access
seems to have a 'really good go' at connecting to the back end.

I think I'll just test for 3043, Disk or Network error, and in that case do
something different.
Btw, if you have intermittent loss of network, then you will likely
have backend corruption waiting to happen (I'm assuming MDB backend).
We've had this quite a lot and the MDB seems fine. Is there any sort of test
for incipient corruption?
With Win2000 and up, you can display the network icon in the taskbar,
and it will popup a balloon when it reconnects.

I don't think it's that sort of loss of connection. More very temporary. We
suspect a dodgy switch (mainly cause that's about the only thing that hasn't
been replaced over the last few weeks).

Cheers, Mike

[Danny J. Lesandrini]

FWIW with respect to error handlers, I've recently added a new feature.
A few months ago, I wrote a silly article about how to pass small amounts
of data from your Access app, through the firewall to an off-site database.

http://www.databasejournal.com/featu...le.php/3491216

After that, I came up with the idea of having my client mdbs log the errors
locally, but also send a copy to my server, via an ASP page that inserts the
data. You can see it for yourself at this site

http://www.amazecreations.com/Client...ort=1&filter=2

I simply add this function and call it from my error handler. So, even if the
user's network server is unavailable, I still see the message, so long as their
Internet connection doesn't go down.

This has really helped me to be responsive. I keep the link on my browser
toolbar and check them periodically throughout the day. I've called my client
before they called me to say I'm working on an issue I saw posted to my
error site. That really impressed them!

Danny J. Lesandrini
dl*********@hotmail.com
http://amazecreations.com/datafast/

Public Function UpdateDataFastWebErrorLog(ByVal lErr As Long, _
sDescr As String, sObject As String, sFunction As String, _
lLine As Long, sLogin As String, sUser As String) As Long
On Error Resume Next

Dim objDoc As SHDocVw.InternetExplorer
Dim strSURL As String

strSURL = ""

strSURL = strSURL & "?client=" & gcstr_Client
strSURL = strSURL & "&err=" & lErr
strSURL = strSURL & "&descr=" & sDescr
strSURL = strSURL & "&obj=" & sObject
strSURL = strSURL & "&fn=" & sFunction
strSURL = strSURL & "&line=" & lLine
strSURL = strSURL & "&login=" & sLogin
strSURL = strSURL & "&user=" & sUser
strSURL = strSURL & "&ID=-1&btnSave=yes"

Set objDoc = New SHDocVw.InternetExplorer
objDoc.Navigate strSURL, , , True

' Need something to pause execution while URL is hit.
ForcePause 1

UpdateDataFastWebErrorLog = Err.Number
End Function
Sub ForcePause(lSeconds As Long)
On Error GoTo Err_Handler

Dim lngPauseTime As Long ' The time to pause for
Dim lngStart As Long ' The start time
Dim lngFinish As Long ' The finish time of the timer function

lngPauseTime = lSeconds
lngStart = Timer ' Set start time.

' Do while the Timer is less than the start and the seconds to wait
Do While Timer < lngStart + lSeconds
' Pass control to the OS
DoEvents
Loop
lngFinish = Timer ' Set end time.

Exit_Here:
Exit Sub
Err_Handler:
' log error
Resume Exit_Here
End Sub

[Mike MacSween]

That looks great Danny, will investigate.

Thanks, Mike

"Danny J. Lesandrini" <dl*********@hotmail.com> wrote in message
news:dK********************@comcast.com...

FWIW with respect to error handlers, I've recently added a new feature.
A few months ago, I wrote a silly article about how to pass small amounts
of data from your Access app, through the firewall to an off-site
database.

http://www.databasejournal.com/featu...le.php/3491216

After that, I came up with the idea of having my client mdbs log the
errors
locally, but also send a copy to my server, via an ASP page that inserts
the
data. You can see it for yourself at this site

http://www.amazecreations.com/Client...ort=1&filter=2

I simply add this function and call it from my error handler. So, even if
the
user's network server is unavailable, I still see the message, so long as
their
Internet connection doesn't go down.

This has really helped me to be responsive. I keep the link on my browser
toolbar and check them periodically throughout the day. I've called my
client
before they called me to say I'm working on an issue I saw posted to my
error site. That really impressed them!

Danny J. Lesandrini
dl*********@hotmail.com
http://amazecreations.com/datafast/

Public Function UpdateDataFastWebErrorLog(ByVal lErr As Long, _
sDescr As String, sObject As String, sFunction As String, _
lLine As Long, sLogin As String, sUser As String) As Long
On Error Resume Next

Dim objDoc As SHDocVw.InternetExplorer
Dim strSURL As String

strSURL = ""

strSURL = strSURL & "?client=" & gcstr_Client
strSURL = strSURL & "&err=" & lErr
strSURL = strSURL & "&descr=" & sDescr
strSURL = strSURL & "&obj=" & sObject
strSURL = strSURL & "&fn=" & sFunction
strSURL = strSURL & "&line=" & lLine
strSURL = strSURL & "&login=" & sLogin
strSURL = strSURL & "&user=" & sUser
strSURL = strSURL & "&ID=-1&btnSave=yes"

Set objDoc = New SHDocVw.InternetExplorer
objDoc.Navigate strSURL, , , True

' Need something to pause execution while URL is hit.
ForcePause 1

UpdateDataFastWebErrorLog = Err.Number
End Function
Sub ForcePause(lSeconds As Long)
On Error GoTo Err_Handler

Dim lngPauseTime As Long ' The time to pause for
Dim lngStart As Long ' The start time
Dim lngFinish As Long ' The finish time of the timer function

lngPauseTime = lSeconds
lngStart = Timer ' Set start time.

' Do while the Timer is less than the start and the seconds to wait
Do While Timer < lngStart + lSeconds
' Pass control to the OS
DoEvents
Loop
lngFinish = Timer ' Set end time.

Exit_Here:
Exit Sub
Err_Handler:
' log error
Resume Exit_Here
End Sub

[Danny J. Lesandrini]

Implementing it the first time isn't trivial. I'd have to get you the
ASP code and the database, though what you see in the DBJ article
is what I used as a basis.

When I get a new customer, I just change the TEST to whatever
acronym I'm using for their app and rename the page accordingly.
Takes me less than 10 minutes to add a new client to the site.

If anyone is interested, let me know and I'll zip up a package of
all the ASP pages, etc. You're welcome to it, but understand that
it's still a new idea and completely unsupported.
--

Danny J. Lesandrini
dl*********@hotmail.com
http://amazecreations.com/datafast/

"Mike MacSween" <mi******************@btinternet.com> wrote ...

That looks great Danny, will investigate.

Thanks, Mike

[Danny J. Lesandrini]

Aww, heck ... it isn't that hard to just add it to my downloads.
It's now there, titled ASP Client Error Log

http://amazecreations.com/datafast/G...ntErrorLog.zip

http://amazecreations.com/datafast/
--
danny

[David W. Fenton]

"Mike MacSween" <mi******************@btinternet.com> wrote in
news:43***********************@news.aaisp.net.uk:

Or has anybody got a VBA version of ping?

If your back end is on a shared server, then Access is already
testing the linke about once a second, which is how often it "pings"
the LDB file. That's why the error can pop up when the app is
inactive.

Remember, the problem can occur because of a corrupted (or partially
corrupted, i.e., corruption that doesn't always announce itself)
back end just as much as it can occur because of a lost network
connection.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[David W. Fenton]

"Mike MacSween" <mi******************@btinternet.com> wrote in
news:43***********************@news.aaisp.net.uk:

More very temporary. We
suspect a dodgy switch (mainly cause that's about the only thing
that hasn't been replaced over the last few weeks).

???

If the app used to work OK and you've replaced everything *but* the
switch, then that would be the *last* thing I'd blame the problem
on.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[David W. Fenton]

"Danny J. Lesandrini" <dl*********@hotmail.com> wrote in
news:dK********************@comcast.com:

This has really helped me to be responsive. I keep the link on my
browser toolbar and check them periodically throughout the day.
I've called my client before they called me to say I'm working on
an issue I saw posted to my error site. That really impressed
them!

It's too bad that such a nice function is based on IE. I would
*never* force my clients to depend on such a pile of crap for any of
their app's functionality.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[David W. Fenton]

"Danny J. Lesandrini" <dl*********@hotmail.com> wrote in
news:f6********************@comcast.com:

Implementing it the first time isn't trivial. I'd have to get you
the ASP code and the database, though what you see in the DBJ
article is what I used as a basis.

???

Is it not the case that the web server could be written in any
server-side scripting language? I didn't read your code carefully
once I saw that it was dependent on IE (which makes it useless for
anyone concerned with producing robust and secure applications), but
you're just passing a call to a remote script on a publicly
available web server. The script on that web server could be ASP,
PHP, ColdFusion, Perle or whatever.

I'm not sure why the dependency on IE is needed. I long ago
implemented an upload function in an Access application that ran an
FTP script to upload data, and then called a CGI script on that web
server to process the files. I just used the default web browser (no
browser-specific dependencies).

For posting a single error message (as opposed to processing a group
of tab-delimited data files), one could skip the FTP and pass values
to the web script. The only difference is that your solution is
quite, whereas mine pops up a web browser window.

I think that if I were implementing this, I'd use the same FTP plus
executing the URL to call the script. The FTP would create a text
file with the error report. The URL would process that text file. I
think I'd implement the web-side application to poll the FTP drop
folder periodically, and give the user the option of reporting
immediately. If they choose not to, the message will be reported
within the interval I've chosen for polling.

That would remove any dependency on IE.

Of course, there's the firewall issue that you say your app solves.
I'm not sure how or why, because it defeats the purpose of having a
firewall. I think I'd set up a local proxy server in order to allow
users to communicate with a web app.

Interesing ideas.

Too bad you chose the Microsoft-dependent route for implementing it.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[Danny J. Lesandrini]

David:

Don't sugar-coat it ... tell us what you REALLY think of IE.

You're probably correct about all of the observations you made, but
I used IE because it's what I know, it's fast and easy. ASP pages
are simple to churn out and is a technology I've been using for years.

As for forcing the users to have IE, I'm not sure that it's such a big
stretch. Do Windows users really uninstall Internet Explorer when
they install FireFox? No, it still sits there and my code merely employs
(quietly, as you correctly observed) the libraries of IE that are already
installed and registered on Windows.

True, this doesn't mitigate any potential security holes, but the user
never actually sees or loads the IE browser. Do _you_ know how one
would leverage security flaws in this scenario? If you do, don't tell,
but I suspect the process I described adds a layer of complexity to
the hack so as to make it improbable, if not impossible.

But, what do I know. Not much, really. It's like SQL Injection on
ASP pages. One person responded to one of my articles to say that
they could use SQL Injection to wreak havoc on my database. Well,
I didn't get angry or defensive, but I replied to him with a challenge
to do it. I mean, if my code is vulnerable, then I want to know. He
never replied, and my sites are safe to this day.

My sites are safe, not because I am so brilliant that I devised a
scheme to thwart SQL Injection, but because it's just not that easy
to perpetrate. I've read the articles and tested the hacks on my own
pages, and couldn't break my code. Again, not because of my great
expertise or foresight, but because it's just not that easy to do.

I suspect the same is true with Internet Explorer security holes ... and
with the holes in EVERY other browser. The only reason that IE gets
all the press is because it's everywhere and if I were a hacker, I
wouldn't waste my time trying to beat a browser that has 7% of the
market ... I'd go for the payoff.

Now, I'm talking out of my hat here, so don't be rough on me if you
feel the need to correct my thinking. This is how it all seems to me,
based on my experience with web pages and databases over the
last 5 years or so. I could be wrong, but I'm entitled to my opinion
as much as the next coder.
--
Danny
"David W. Fenton" <dX********@bway.net.invalid> wrote

It's too bad that such a nice function is based on IE. I would
*never* force my clients to depend on such a pile of crap for any
of their app's functionality.

[jimfortune]

Danny J. Lesandrini wrote:

I suspect the same is true with Internet Explorer security holes ... and
with the holes in EVERY other browser. The only reason that IE gets
all the press is because it's everywhere and if I were a hacker, I
wouldn't waste my time trying to beat a browser that has 7% of the
market ... I'd go for the payoff.

I opine that the fascination of IE with hackers doesn't lie entirely
with how many machines will be affected. I suspect MS has stepped on
some toes along the way and the owners of those toes may be
specifically targeting MS products as a way to embarass MS and enact
some vengance. Of course the fact that MS dutifully reports security
flaws also makes it easier for hackers to create hacks based on those
flaws hoping that admins will not keep up-to-date.

James A. Fortune

[Mike MacSween]

"David W. Fenton" <dX********@bway.net.invalid> wrote in message
news:Xn**********************************@216.196. 97.142...

"Mike MacSween" <mi******************@btinternet.com> wrote in
news:43***********************@news.aaisp.net.uk:

More very temporary. We
suspect a dodgy switch (mainly cause that's about the only thing
that hasn't been replaced over the last few weeks).

???

If the app used to work OK and you've replaced everything *but* the
switch, then that would be the *last* thing I'd blame the problem
on.

It used to do this with old workstations, with an old server. Then the old
network admin did some work on something and the problem went away.

Since then they've got a new sysadmin, new workstations and now a new
server, and the problem has reappeared. But only, it seems, after I moved
the BE onto the new server.

It seems to happen in groups. Previously it was machines in one room, now
it's machines in another. I don't actually know what switches/hubs/routers
there are. But you can see what I'm thinking maybe? A group of machines that
were all on the same switch. The place has had some work and now a different
group of machines is on that switch. Or something like that.

The network admin are going to look at the switch cupboard next. We'll see.

Mike

[Mike MacSween]

"David W. Fenton" <dX********@bway.net.invalid> wrote in message
news:Xn**********************************@216.196. 97.142...

"Mike MacSween" <mi******************@btinternet.com> wrote in
news:43***********************@news.aaisp.net.uk:

Or has anybody got a VBA version of ping?
If your back end is on a shared server, then Access is already
testing the linke about once a second, which is how often it "pings"
the LDB file.

Right, it does that does it? Is there any way I can grab the result of that
'ping'? Before it starts to chuck up errors? Presumably it's not actually
called a ping.
That's why the error can pop up when the app is
inactive.
Ah ha.
Remember, the problem can occur because of a corrupted (or partially
corrupted, i.e., corruption that doesn't always announce itself)
back end just as much as it can occur because of a lost network
connection.

Any way to test for unannounced corruption?

Thanks, Mike

[Chuck Grimsby]

On Wed, 14 Sep 2005 12:40:48 -0500, "David W. Fenton"
<dX********@bway.net.invalid> wrote:

"Danny J. Lesandrini" <dl*********@hotmail.com> wrote in
news:dK********************@comcast.com:

This has really helped me to be responsive. I keep the link on my
browser toolbar and check them periodically throughout the day.
I've called my client before they called me to say I'm working on
an issue I saw posted to my error site. That really impressed
them!

It's too bad that such a nice function is based on IE. I would
*never* force my clients to depend on such a pile of crap for any of
their app's functionality.

Granted I just took a _quick_ look at what Danny was doing, but I
didn't see anything that was _truly_ IE dependent. Danny's
implementation of doing this sort of thing is, but remember that Danny
is showing _how_ something can be done, not how it _must_ be done.

I've actually done much the same thing myself in some of my own
applications, and none of it _required_ IE, or the reference to IE. I
just build the HTTP request in VBA, and START the HTTP request string,
rather the setting a reference to IE and using all it's nice built-in
stuff.

The _real_ problem with doing things like this is designing/running
_sites_ that are multi-browser aware. IE's DOM is different then
Firefox/Mozilla, which is different the Opera, which is different then
______ (fill in the blank for whatever browser you wish, and repeat ad
nauseum).

What happens at the site isn't the issue, it's what happens at the
browser. Java and javascript for some pretty big issues, whether or
not animations are shown/played/repeated is another problem. In order
to make a site multi-browser aware, you have to program the site to
detect and adapt for as many browsers as you care to support. And
then you hope someone doesn't go into a big hissy fit when they change
their browsers "User-Agent" response to impersonate some other
browser, and then try to access your site with that switch in place.
(For fun, grab the "User Agent Switcher" Extension off of FireFox's
site, and surf the web for a while with it set to "IE 6" or something,
and watch all the websites "screw up" until you switch it back.
Opps!)

Hey, Danny! For round 2 of that application.... Build a RSS feed to
show the users what bugs have been reported and their status. I
haven't had to do that myself yet, so it'd be fun to see what you come
up with.
--
Drive C: Error. (A)bort (R)etry (S)mack The Darned Thing

[David W. Fenton]

"Mike MacSween" <mi******************@btinternet.com> wrote in
news:43***********************@news.aaisp.net.uk:

"David W. Fenton" <dX********@bway.net.invalid> wrote in message
news:Xn**********************************@216.196. 97.142...

"Mike MacSween" <mi******************@btinternet.com> wrote in
news:43***********************@news.aaisp.net.uk:

Or has anybody got a VBA version of ping?

If your back end is on a shared server, then Access is already
testing the linke about once a second, which is how often it
"pings" the LDB file.

Right, it does that does it? Is there any way I can grab the
result of that 'ping'? Before it starts to chuck up errors?
Presumably it's not actually called a ping.

I don't believe so. I think Access craps out with the "Disk or
Network Error" message the minute one of those pings fail. But
that's must my supposition -- I have no hard facts about that.

That's why the error can pop up when the app is
inactive.

Ah ha.

Well, remember the way multi-user record locking works -- it's
managed by each workstation reading data out of the shared LDB file.

Remember, the problem can occur because of a corrupted (or
partially corrupted, i.e., corruption that doesn't always
announce itself) back end just as much as it can occur because of
a lost network connection.

Any way to test for unannounced corruption?

No, but you can run it through the wringer and recreate a fresh MDB
that will have absolutely no possibility of any corruption. It's
lots of work, but it's *much* easier to do that than it is to
troubleshoot a network!

Been there, done that!

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[Tom van Stiphout]

On Wed, 14 Sep 2005 23:06:12 +0100, "Mike MacSween"
<mi******************@btinternet.com> wrote:

We once had a client with an MDB that didn't compact anymore. We wrote
code that looped over all tables and all records and all fields and
tried to read them. That's how we found the corrupt memo fields.
That's just one form of corruption, though.

-Tom.

"David W. Fenton" <dX********@bway.net.invalid> wrote in message
news:Xn**********************************@216.196 .97.142...

"Mike MacSween" <mi******************@btinternet.com> wrote in
news:43***********************@news.aaisp.net.uk:

Or has anybody got a VBA version of ping?

If your back end is on a shared server, then Access is already
testing the linke about once a second, which is how often it "pings"
the LDB file.

Right, it does that does it? Is there any way I can grab the result of that
'ping'? Before it starts to chuck up errors? Presumably it's not actually
called a ping.

That's why the error can pop up when the app is
inactive.

Ah ha.

Remember, the problem can occur because of a corrupted (or partially
corrupted, i.e., corruption that doesn't always announce itself)
back end just as much as it can occur because of a lost network
connection.

Any way to test for unannounced corruption?

Thanks, Mike

[David W. Fenton]

"Mike MacSween" <mi******************@btinternet.com> wrote in
news:43***********************@news.aaisp.net.uk:

"David W. Fenton" <dX********@bway.net.invalid> wrote in message
news:Xn**********************************@216.196. 97.142...

"Mike MacSween" <mi******************@btinternet.com> wrote in
news:43***********************@news.aaisp.net.uk:

More very temporary. We
suspect a dodgy switch (mainly cause that's about the only thing
that hasn't been replaced over the last few weeks).
???

If the app used to work OK and you've replaced everything *but*
the switch, then that would be the *last* thing I'd blame the
problem on.

It used to do this with old workstations, with an old server. Then
the old network admin did some work on something and the problem
went away.

Since then they've got a new sysadmin, new workstations and now a
new server, and the problem has reappeared. But only, it seems,
after I moved the BE onto the new server.

Is that file server also a Microsoft Exchange server? I've found
that Exchange does not work well at all on a file server storing
shared MDB files.
It seems to happen in groups. Previously it was machines in one
room, now it's machines in another. I don't actually know what
switches/hubs/routers there are. But you can see what I'm thinking
maybe? A group of machines that were all on the same switch. The
place has had some work and now a different group of machines is
on that switch. Or something like that.
Well, that's a different story. If all the machines having the
problem are on the same isolated network segment, the first place to
start is with the switch for that network segment.
The network admin are going to look at the switch cupboard next.
We'll see.

Well, when reacting above I didn't know that the network was
partitioned and that the problems were occuring on only one isolated
network segment. That does make the switch look more like a possible
cause.

But it could be any number of other things as well.

I recently had a situation on a small peer-to-peer network where
everything worked great for the 3 workstations until the boss
plugged in her new THinkpad laptop, then everybody else started
getting disk or network errors. Turns out the problem went away when
was put in a new NIC on the workstation that was serving as the file
server!

We'd already tried a new NIC for the laptop, and that seemed to fix
it, but then the problem came back. The NIC on the peer-to-peer
server had been operating fine with the other machines for nearly 3
years!

So all sorts of weird things can cause these problems, and they
don't always make sense.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[David W. Fenton]

"Danny J. Lesandrini" <dl*********@hotmail.com> wrote in
news:vf********************@comcast.com:

David:

Don't sugar-coat it ... tell us what you REALLY think of IE.

You're probably correct about all of the observations you made,
but I used IE because it's what I know, it's fast and easy. ASP
pages are simple to churn out and is a technology I've been using
for years.

As for forcing the users to have IE, I'm not sure that it's such a
big stretch. . .
Your missing the point -- every Windows user has IE. I said forcing
a *dependency* on IE on the end users. IE is a component of Windows
that is so intertwined with so many different subsystems and is a
huge security risk. Because of that it is constantly being patched
by Microsoft to try to rectify all the bugs and vulnerabilities in
it. By introducing a dependency on IE, you're exposing your users to
the risk of your app breaking if one of the frequent patches to IE
(or some Windows component that is related to IE) breaks the
functionality you're depending on.
. . . Do Windows users really uninstall Internet Explorer
when they install FireFox? No, it still sits there and my code
merely employs (quietly, as you correctly observed) the libraries
of IE that are already installed and registered on Windows.
I have IE blocked at my software firewall -- it can't connect to
anything not on my PC. I use it only for testing web pages.
True, this doesn't mitigate any potential security holes, but the
user never actually sees or loads the IE browser. Do _you_ know
how one would leverage security flaws in this scenario? If you
do, don't tell, but I suspect the process I described adds a layer
of complexity to the hack so as to make it improbable, if not
impossible.
I'm not saying your code is a security hole, but that depending on
IE introduces what I see as an un-needed outside dependency. I don't
like my apps to have outside dependencies, unless I am guarantee
that this dependency is stable. Standards not controlled by
Microsoft, or Windows APIs are stable, in mky opinion. You can count
on a URL being executed by whatever program a PC is set to use for
executing them. Windows APIs are stable and safe.

Anything else I see as questionable.
But, what do I know. Not much, really. It's like SQL Injection
on ASP pages. One person responded to one of my articles to say
that they could use SQL Injection to wreak havoc on my database.
Well, I didn't get angry or defensive, but I replied to him with a
challenge to do it. I mean, if my code is vulnerable, then I want
to know. He never replied, and my sites are safe to this day.
I don't know what SQL injection is, but if your code is vulnerable,
I'd fix it. I hear that a lot of people are having their websites'
contact forms hammered by scripts trying to see if they can exploit
them to spam. It's happening even to scripts that are invulnerable
to these kinds of exploits (if you're validating all of the data
that's going in the headers (e.g., using regular expressions) you're
safe). So, just because no one has done it yet doesn't mean that it
won't happen any time. If you know the vulnerability is there, you
ought to do what you can to remove it.
My sites are safe, not because I am so brilliant that I devised a
scheme to thwart SQL Injection, but because it's just not that
easy to perpetrate. I've read the articles and tested the hacks
on my own pages, and couldn't break my code. Again, not because
of my great expertise or foresight, but because it's just not that
easy to do.
Well, I don't know the details, but if I knew of an exploit, I'd be
sure to do what I could to prevent it.
I suspect the same is true with Internet Explorer security holes
... and with the holes in EVERY other browser. . . .
But it's *not* the same. IE is much more insecure and much less
frequently patched than, say, Firefox. Go to Secunia.com and check
out the security reports on IE6.x and Firefox 1.x and look at the
number of vulnerabilities over time. Look at the number of ones
Secunia classifies as serious. Look at the number of unpatched
vulnerabilities, and check out how many are truly serious exploits.
Look at the amount of time it takes MS to patch vs. Firefox, and
you'll see that the two browsers are simply not comparable at all in
terms of vulnerability or responsiveness to fixing vulnerabilities.
. . . The only reason
that IE gets all the press is because it's everywhere and if I
were a hacker, I wouldn't waste my time trying to beat a browser
that has 7% of the market ... I'd go for the payoff.
IE gets the press because it's got more serious vulnerabilities and
because MS doesn't patch them.

Comnare the history and current status of the two vulnerabilities
listed on the Secunia front page. The IE exploit was announced Aug.
25th. MS's workaround makes IE virtually unusable (by giving you
lots of pop-up security confirmations to click through). The Firefox
vulnerability was announced on Sept. 6th and the Mozilla foundation
has released a patch that changes your configuration. It takes away
a small piece of functionality that very few people ever use. You
don't even need the patch -- you can easily change the setting
yourself.
Now, I'm talking out of my hat here, so don't be rough on me if
you feel the need to correct my thinking. This is how it all
seems to me, based on my experience with web pages and databases
over the last 5 years or so. I could be wrong, but I'm entitled
to my opinion as much as the next coder.

Well, you're writing articles that advise other people on how to do
things. Just because it's cool doesn't mean it's advisable.

I especially think it's unwise to introduce outside dependencies
when there are alternative methods for accomplishing the same takss.
They might not be as slick, but if it make syour app more robust, I
can't see that there's a problem with that tradeoff.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[David W. Fenton]

Chuck Grimsby <c.*******@worldnet.att.net.invalid> wrote in
news:r2********************************@4ax.com:

On Wed, 14 Sep 2005 12:40:48 -0500, "David W. Fenton"
<dX********@bway.net.invalid> wrote:

"Danny J. Lesandrini" <dl*********@hotmail.com> wrote in
news:dK********************@comcast.com:

This has really helped me to be responsive. I keep the link on
my browser toolbar and check them periodically throughout the
day. I've called my client before they called me to say I'm
working on an issue I saw posted to my error site. That really
impressed them!

It's too bad that such a nice function is based on IE. I would
*never* force my clients to depend on such a pile of crap for any
of their app's functionality.

Granted I just took a _quick_ look at what Danny was doing, but I
didn't see anything that was _truly_ IE dependent. . . .

So far as I can see, it's using the embedded IE core, and interfaces
specific to that IE component, so:
. . . Danny's
implementation of doing this sort of thing is, but remember that
Danny is showing _how_ something can be done, not how it _must_ be
done.
But his method is completely dependent on the IE component he's
using to do it.
I've actually done much the same thing myself in some of my own
applications, and none of it _required_ IE, or the reference to
IE. I just build the HTTP request in VBA, and START the HTTP
request string, rather the setting a reference to IE and using all
it's nice built-in stuff.
OK, that seems like a good way to do it. But if you're not going to
pop a browser window, how is the HTTP request sent? How do you
manage to bypass the firewall, as Danny says his code does (I didn't
read it in detail to see how that's accomplished)?
The _real_ problem with doing things like this is
designing/running _sites_ that are multi-browser aware. IE's DOM
is different then Firefox/Mozilla, which is different the Opera,
which is different then ______ (fill in the blank for whatever
browser you wish, and repeat ad nauseum).
IE is the outlier. All the other browser you mention are built
around W3C standards. It's IE that is the broken browser in regard
to standards compliance, and Microsoft has no interest in fixing it.
-- they've said outright that their new IE 7 will *not* fix any
significant number of the standards violations built into IE.

It has also long annoyed me that everyone treats IE as if it's a
single browser, when, in fact, there are FOUR distinct rendering
engines, each with its own quirks (not even considering IE3.x,
there's IE4.x, IE5.1, IE5.5 and IE6.x). There are almost as many
differences between the IE versions as there are between any single
IE version and other browsers.

So even coding *just* for IE means using a lot of workarounds.

Of course, this only matters for complex layouts. For the kind of
things an Access app should be sending via HTTP, I think it hardly
matters. It's more an issue for the designers of websites than it is
for Access developers.
What happens at the site isn't the issue, it's what happens at the
browser. . . .
I thought Danny's code didn't open a browser window, that it used
the IE components to do the job behind the scenes, without actually
opening a browser to do it.
. . . Java and javascript for some pretty big issues, whether
or not animations are shown/played/repeated is another problem.
In order to make a site multi-browser aware, you have to program
the site to detect and adapt for as many browsers as you care to
support. And then you hope someone doesn't go into a big hissy
fit when they change their browsers "User-Agent" response to
impersonate some other browser, and then try to access your site
with that switch in place. (For fun, grab the "User Agent
Switcher" Extension off of FireFox's site, and surf the web for a
while with it set to "IE 6" or something, and watch all the
websites "screw up" until you switch it back. Opps!)
If you're delivering standards-compliant HTML, the browser agent
should be irrelevant.

So far as I know, there's never any need to care about an individual
user's browser. You can deliver up appropriate HTML + CSS simply by
using the old IMPORT trick (version 4 browsers can't read the
imported stylesheet, so all the post-version 4 CSS goes in the style
sheet loaded with the IMPORT).
Hey, Danny! For round 2 of that application.... Build a RSS feed
to show the users what bugs have been reported and their status.
I haven't had to do that myself yet, so it'd be fun to see what
you come up with.

I think you're talking about a completely different set of issues
from the one I raised.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[Mike MacSween]

"David W. Fenton" <dX********@bway.net.invalid> wrote in message
news:Xn**********************************@216.196. 97.142...

"Mike MacSween" <mi******************@btinternet.com> wrote in
news:43***********************@news.aaisp.net.uk:

Since then they've got a new sysadmin, new workstations and now a
new server, and the problem has reappeared. But only, it seems,
after I moved the BE onto the new server.

Is that file server also a Microsoft Exchange server? I've found
that Exchange does not work well at all on a file server storing
shared MDB files.

As it happens, yes. The old server wasn't but the new one is. Is it Exchange
that has the problems or Access?

It seems to happen in groups. Previously it was machines in one
room, now it's machines in another. I don't actually know what
switches/hubs/routers there are. But you can see what I'm thinking
maybe? A group of machines that were all on the same switch. The
place has had some work and now a different group of machines is
on that switch. Or something like that.

Well, that's a different story. If all the machines having the
problem are on the same isolated network segment, the first place to
start is with the switch for that network segment.

I don't know it the network is divided into 'segments' or not. It's
certainly all on the same subnet.

Mike

[Mike MacSween]

"David W. Fenton" <dX********@bway.net.invalid> wrote in message
news:Xn**********************************@216.196. 97.142...

"Mike MacSween" <mi******************@btinternet.com> wrote in
news:43***********************@news.aaisp.net.uk:

"David W. Fenton" <dX********@bway.net.invalid> wrote in message
news:Xn**********************************@216.196. 97.142...

"Mike MacSween" <mi******************@btinternet.com> wrote in
news:43***********************@news.aaisp.net.uk:

Or has anybody got a VBA version of ping?

If your back end is on a shared server, then Access is already
testing the linke about once a second, which is how often it
"pings" the LDB file.

Right, it does that does it? Is there any way I can grab the
result of that 'ping'? Before it starts to chuck up errors?
Presumably it's not actually called a ping.

I don't believe so. I think Access craps out with the "Disk or
Network Error" message the minute one of those pings fail. But
that's must my supposition -- I have no hard facts about that.

Where did you find out about these 'pings'. There's no point me writing some
routine that just duplicates what Access is doing anyway.

Mike

[Chuck Grimsby]

On Wed, 14 Sep 2005 23:15:51 -0500, "David W. Fenton"
<dX********@bway.net.invalid> wrote:

Chuck Grimsby <c.*******@worldnet.att.net.invalid> wrote in
news:r2********************************@4ax.com :

On Wed, 14 Sep 2005 12:40:48 -0500, "David W. Fenton"
<dX********@bway.net.invalid> wrote:

"Danny J. Lesandrini" <dl*********@hotmail.com> wrote in
news:dK********************@comcast.com:

This has really helped me to be responsive. I keep the link on
my browser toolbar and check them periodically throughout the
day. I've called my client before they called me to say I'm
working on an issue I saw posted to my error site. That really
impressed them!

It's too bad that such a nice function is based on IE. I would
*never* force my clients to depend on such a pile of crap for any
of their app's functionality.

Granted I just took a _quick_ look at what Danny was doing, but I
didn't see anything that was _truly_ IE dependent. . . .

So far as I can see, it's using the embedded IE core, and interfaces
specific to that IE component, so:

. . . Danny's
implementation of doing this sort of thing is, but remember that
Danny is showing _how_ something can be done, not how it _must_ be
done.

But his method is completely dependent on the IE component he's
using to do it.

I've actually done much the same thing myself in some of my own
applications, and none of it _required_ IE, or the reference to
IE. I just build the HTTP request in VBA, and START the HTTP
request string, rather the setting a reference to IE and using all
it's nice built-in stuff.

OK, that seems like a good way to do it. But if you're not going to
pop a browser window, how is the HTTP request sent? How do you
manage to bypass the firewall, as Danny says his code does (I didn't
read it in detail to see how that's accomplished)?

The _real_ problem with doing things like this is
designing/running _sites_ that are multi-browser aware. IE's DOM
is different then Firefox/Mozilla, which is different the Opera,
which is different then ______ (fill in the blank for whatever
browser you wish, and repeat ad nauseum).

IE is the outlier. All the other browser you mention are built
around W3C standards. It's IE that is the broken browser in regard
to standards compliance, and Microsoft has no interest in fixing it.
-- they've said outright that their new IE 7 will *not* fix any
significant number of the standards violations built into IE.

It has also long annoyed me that everyone treats IE as if it's a
single browser, when, in fact, there are FOUR distinct rendering
engines, each with its own quirks (not even considering IE3.x,
there's IE4.x, IE5.1, IE5.5 and IE6.x). There are almost as many
differences between the IE versions as there are between any single
IE version and other browsers.

So even coding *just* for IE means using a lot of workarounds.

Of course, this only matters for complex layouts. For the kind of
things an Access app should be sending via HTTP, I think it hardly
matters. It's more an issue for the designers of websites than it is
for Access developers.

What happens at the site isn't the issue, it's what happens at the
browser. . . .

I thought Danny's code didn't open a browser window, that it used
the IE components to do the job behind the scenes, without actually
opening a browser to do it.

. . . Java and javascript for some pretty big issues, whether
or not animations are shown/played/repeated is another problem.
In order to make a site multi-browser aware, you have to program
the site to detect and adapt for as many browsers as you care to
support. And then you hope someone doesn't go into a big hissy
fit when they change their browsers "User-Agent" response to
impersonate some other browser, and then try to access your site
with that switch in place. (For fun, grab the "User Agent
Switcher" Extension off of FireFox's site, and surf the web for a
while with it set to "IE 6" or something, and watch all the
websites "screw up" until you switch it back. Opps!)

If you're delivering standards-compliant HTML, the browser agent
should be irrelevant.

So far as I know, there's never any need to care about an individual
user's browser. You can deliver up appropriate HTML + CSS simply by
using the old IMPORT trick (version 4 browsers can't read the
imported stylesheet, so all the post-version 4 CSS goes in the style
sheet loaded with the IMPORT).

Hey, Danny! For round 2 of that application.... Build a RSS feed
to show the users what bugs have been reported and their status.
I haven't had to do that myself yet, so it'd be fun to see what
you come up with.

I think you're talking about a completely different set of issues
from the one I raised.

David, I don't want to get into a big discussion here on whether or
not IE is "good" or "bad". This is the *wrong* forum for such
discussions. If you want to have such a discussion, you might want to
try one of the advocacy forums.

Yes, Danny's implementation _shows_ how to do it with IE, what I am
saying is that such a mechanism doesn't _require_ IE's use. Heck, it
really doesn't even require a browser at all!

You can do it all with API calls, if you wanted to, but Danny's
readership probably isn't into all that, so he probably isn't going to
post code showing how to do it that way. It would be a great way to
rid himself of his readers!
--
Drive C: Error. (A)bort (R)etry (S)mack The Darned Thing

[David W. Fenton]

"Mike MacSween" <mi******************@btinternet.com> wrote in
news:43***********************@news.aaisp.net.uk:

"David W. Fenton" <dX********@bway.net.invalid> wrote in message
news:Xn**********************************@216.196. 97.142...

"Mike MacSween" <mi******************@btinternet.com> wrote in
news:43***********************@news.aaisp.net.uk:

"David W. Fenton" <dX********@bway.net.invalid> wrote in message
news:Xn**********************************@216.196. 97.142...
"Mike MacSween" <mi******************@btinternet.com> wrote in
news:43***********************@news.aaisp.net.uk:

> Or has anybody got a VBA version of ping?

If your back end is on a shared server, then Access is already
testing the linke about once a second, which is how often it
"pings" the LDB file.

Right, it does that does it? Is there any way I can grab the
result of that 'ping'? Before it starts to chuck up errors?
Presumably it's not actually called a ping.

I don't believe so. I think Access craps out with the "Disk or
Network Error" message the minute one of those pings fail. But
that's must my supposition -- I have no hard facts about that.

Where did you find out about these 'pings'. There's no point me
writing some routine that just duplicates what Access is doing
anyway.

I used a network packet analyzer to monitor traffic from my local PC
to a server. It sent data once a second when I had an MDB open on
that server. As soon as I shut Access, the once-a-second packets
stopped.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[David W. Fenton]

"Mike MacSween" <mi******************@btinternet.com> wrote in
news:43***********************@news.aaisp.net.uk:

"David W. Fenton" <dX********@bway.net.invalid> wrote in message
news:Xn**********************************@216.196. 97.142...

"Mike MacSween" <mi******************@btinternet.com> wrote in
news:43***********************@news.aaisp.net.uk:

Since then they've got a new sysadmin, new workstations and now
a new server, and the problem has reappeared. But only, it
seems, after I moved the BE onto the new server.

Is that file server also a Microsoft Exchange server? I've found
that Exchange does not work well at all on a file server storing
shared MDB files.

As it happens, yes. The old server wasn't but the new one is. Is
it Exchange that has the problems or Access?

I've seen it interfere with things that cause problems for Access. I
prefer to *not* store Access files on an Exchange Server, though I
have one client who is doing so and has been doing so for at least 5
years and hasn't had any corruption problems at all (since getting
all workstations upgraded to Access 2K SR1+ and Jet SP6+).

It seems to happen in groups. Previously it was machines in one
room, now it's machines in another. I don't actually know what
switches/hubs/routers there are. But you can see what I'm
thinking maybe? A group of machines that were all on the same
switch. The place has had some work and now a different group of
machines is on that switch. Or something like that.

Well, that's a different story. If all the machines having the
problem are on the same isolated network segment, the first place
to start is with the switch for that network segment.

I don't know it the network is divided into 'segments' or not.
It's certainly all on the same subnet.

That's not necessarily an indication that it's not segmented. If it
is a switched network, then it is segmented, as opposed to an
unswitched network, where all packets are broadcast to all machines
on the network.

If the network is of any size at all, it's probably segmented with
switches. If the office has more than one switch, then it's
segmented (unless they're running a completely non-standard type of
configuration that uses switches as nothing but hubs).

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[David W. Fenton]

Chuck Grimsby <c.*******@worldnet.att.net.invalid> wrote in
news:i6********************************@4ax.com:

On Wed, 14 Sep 2005 23:15:51 -0500, "David W. Fenton"
<dX********@bway.net.invalid> wrote:
[huge snip]

I think you're talking about a completely different set of issues
from the one I raised.

David, I don't want to get into a big discussion here on whether
or not IE is "good" or "bad". This is the *wrong* forum for such
discussions. If you want to have such a discussion, you might
want to try one of the advocacy forums.

Well, when we're talking about making an Access application
dependent on an IE component, it becomes relevant to this forum. And
that's what Danny posted, code that was dependent on an IE
component. Pointing out the flaws of IE is only pointing out
potential drawbacks of the code that Danny posted.
Yes, Danny's implementation _shows_ how to do it with IE, what I
am saying is that such a mechanism doesn't _require_ IE's use.
Heck, it really doesn't even require a browser at all!
The code would have to be significantly rewritten to not use IE.
You can do it all with API calls, if you wanted to, but Danny's
readership probably isn't into all that, so he probably isn't
going to post code showing how to do it that way. It would be a
great way to rid himself of his readers!

I don't see why someone who can use the code he posted would be
unable to use API calls. that makes no sense to me at all.

But let me point out: you're the one who changed the subject to IE
as a browser *agent*. I was only talking about IE as the HTTP
handler on a local PC, which is all that Danny's code was using it
for (unless I missed the code, and I admit, I didn't read very far
into it).

You changed the subject to what you do to write HTML to render,
while Danny was only using the IE component to send a command to a
remote script via HTTP. No HTML is needed for that, and the IE
rendering engine and all its flaws does not come into the
discussion. That's why I didn't talk about that as one of the flaws
of IE in my response to Danny, becaue those flaws were irrelevant to
the purpose for which Danny was using the IE component.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[David W. Fenton]

Chuck Grimsby <c.*******@worldnet.att.net.invalid> wrote in
news:i6********************************@4ax.com:

David, I don't want to get into a big discussion here on whether
or not IE is "good" or "bad". This is the *wrong* forum for such
discussions. If you want to have such a discussion, you might
want to try one of the advocacy forums.

And another thing:

Pointing out that IE really sucks as a browser is not advocacy. It's
just pointing the obvious fact that anyone who has used other better
browsers or anyone who codes standards-compliant web pages has known
for a very, very long time.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc