.mdb and TCP - weird problem

[ongaro.admin]

Hi,
I'm experiencing a strange problem with .mdb files.
We have two buildings connected by optical fiber (a single LAN).
Everything works perfect with any file, any size, any application
software. The hardware has been tested several times. Viruses, trojans
and so on: clean for sure.
The problem is that .mdb files (_only .mdb files_) often don't open,
are very slow, or even get crashed and corrupted.
The weird is that even copying them using the OS (tested with XP SP2,
W2K, Server 2003) also doesn't work.
TCP traffic analysis using a sniffer reveals a huge mess of errors:
segments lost, duplicate ACKs, retransmission, etc. Impossible to
understand what's happening.
Did anyone ever experienced something similar?

Luca

[Salad]

on**********@ia o.florence.it wrote:

Hi,
I'm experiencing a strange problem with .mdb files.
We have two buildings connected by optical fiber (a single LAN).
Everything works perfect with any file, any size, any application
software. The hardware has been tested several times. Viruses, trojans
and so on: clean for sure.
The problem is that .mdb files (_only .mdb files_) often don't open,
are very slow, or even get crashed and corrupted.
The weird is that even copying them using the OS (tested with XP SP2,
W2K, Server 2003) also doesn't work.
TCP traffic analysis using a sniffer reveals a huge mess of errors:
segments lost, duplicate ACKs, retransmission, etc. Impossible to
understand what's happening.
Did anyone ever experienced something similar?

Luca

Since it's possible your mdb is partially corrupted...

If everyone is out maybe modify your desktop icon temporarily to
something like
"C:\MSACCESS.EX E" "YourMDBPath.md b" /excl
and then compact it

Modify again and add the decompile switch
"C:\MSACCESS.EX E" "YourMDBPath.md b" /excl /decompile

After decompiled, exit out and go back to
"C:\MSACCESS.EX E" "YourMDBPath.md b" /excl
and enter it and compact it and then recompile the app. Fix any
compiler errors if any.

Check and see if you have proper references. Is everybody up to date on
their service packs (Help/About in MS-Access)

Is your reference to DAO 3.6 and others have a ref to DAO 3.51?

Or perhaps create a new mdb and import all the objects (remember to hit
Options to import menus, etc)

Just some things to check.

[ongaro.admin]

On Aug 2, 11:00 am, Salad <o...@vinegar.c omwrote:

ongaro.ad...@ia o.florence.it wrote:

Hi,
I'm experiencing a strange problem with .mdb files.
We have two buildings connected by optical fiber (a single LAN).
Everything works perfect with any file, any size, any application
software. The hardware has been tested several times. Viruses, trojans
and so on: clean for sure.
The problem is that .mdb files (_only .mdb files_) often don't open,
are very slow, or even get crashed and corrupted.
The weird is that even copying them using the OS (tested with XP SP2,
W2K, Server 2003) also doesn't work.
TCP traffic analysis using a sniffer reveals a huge mess of errors:
segments lost, duplicate ACKs, retransmission, etc. Impossible to
understand what's happening.
Did anyone ever experienced something similar?

Luca

Since it's possible your mdb is partially corrupted...

If everyone is out maybe modify your desktop icon temporarily to
something like
"C:\MSACCESS.EX E" "YourMDBPath.md b" /excl
and then compact it

Modify again and add the decompile switch
"C:\MSACCESS.EX E" "YourMDBPath.md b" /excl /decompile

After decompiled, exit out and go back to
"C:\MSACCESS.EX E" "YourMDBPath.md b" /excl
and enter it and compact it and then recompile the app. Fix any
compiler errors if any.

Check and see if you have proper references. Is everybody up to date on
their service packs (Help/About in MS-Access)

Is your reference to DAO 3.6 and others have a ref to DAO 3.51?

Or perhaps create a new mdb and import all the objects (remember to hit
Options to import menus, etc)

Just some things to check.

Thank you,
but we checked all what you suggested already. The problem persists
also with blank empty new .mdb files.
I forgot to mention that no problems occur inside any of the two
single LAN segments, the trouble is just when crossing the optic
fiber, and only with .mdb files (we tried also to rename them, no
way).
It looks to me more something related to the way the filesystem
handles .mdb files. Apparently, it does it in a different way than
other filetypes, making them dramatically sensitive to small
transmission delays.

Luca

[paii, Ron]

<on**********@i ao.florence.itw rote in message
news:11******** **************@ w3g2000hsg.goog legroups.com...

Hi,
I'm experiencing a strange problem with .mdb files.
We have two buildings connected by optical fiber (a single LAN).
Everything works perfect with any file, any size, any application
software. The hardware has been tested several times. Viruses, trojans
and so on: clean for sure.
The problem is that .mdb files (_only .mdb files_) often don't open,
are very slow, or even get crashed and corrupted.
The weird is that even copying them using the OS (tested with XP SP2,
W2K, Server 2003) also doesn't work.
TCP traffic analysis using a sniffer reveals a huge mess of errors:
segments lost, duplicate ACKs, retransmission, etc. Impossible to
understand what's happening.
Did anyone ever experienced something similar?

Luca

Access does not function well over unstable networks and your sniffer
reports a "mess of errors". Access files are NOT sent to the workstation,
they are opened and information is transmitted between the server and
workstation.

[Baz]

I don't believe for a minute that the file system treats mdb files any
differently to any other file. If you get these TCP/IP problems
file-copying mdb files then you are sure to be getting them when copying any
similar-sized file between the same two locations.

Of course, if users have the file open when you are copying it who knows
what disasters might ensue...

<on**********@i ao.florence.itw rote in message
news:11******** **************@ g4g2000hsf.goog legroups.com...

On Aug 2, 11:00 am, Salad <o...@vinegar.c omwrote:

ongaro.ad...@ia o.florence.it wrote:

Hi,
I'm experiencing a strange problem with .mdb files.
We have two buildings connected by optical fiber (a single LAN).
Everything works perfect with any file, any size, any application
software. The hardware has been tested several times. Viruses, trojans
and so on: clean for sure.
The problem is that .mdb files (_only .mdb files_) often don't open,
are very slow, or even get crashed and corrupted.
The weird is that even copying them using the OS (tested with XP SP2,
W2K, Server 2003) also doesn't work.
TCP traffic analysis using a sniffer reveals a huge mess of errors:
segments lost, duplicate ACKs, retransmission, etc. Impossible to
understand what's happening.
Did anyone ever experienced something similar?

Luca

Since it's possible your mdb is partially corrupted...

If everyone is out maybe modify your desktop icon temporarily to
something like
"C:\MSACCESS.EX E" "YourMDBPath.md b" /excl
and then compact it

Modify again and add the decompile switch
"C:\MSACCESS.EX E" "YourMDBPath.md b" /excl /decompile

After decompiled, exit out and go back to
"C:\MSACCESS.EX E" "YourMDBPath.md b" /excl
and enter it and compact it and then recompile the app. Fix any
compiler errors if any.

Check and see if you have proper references. Is everybody up to date on
their service packs (Help/About in MS-Access)

Is your reference to DAO 3.6 and others have a ref to DAO 3.51?

Or perhaps create a new mdb and import all the objects (remember to hit
Options to import menus, etc)

Just some things to check.

Thank you,
but we checked all what you suggested already. The problem persists
also with blank empty new .mdb files.
I forgot to mention that no problems occur inside any of the two
single LAN segments, the trouble is just when crossing the optic
fiber, and only with .mdb files (we tried also to rename them, no
way).
It looks to me more something related to the way the filesystem
handles .mdb files. Apparently, it does it in a different way than
other filetypes, making them dramatically sensitive to small
transmission delays.

Luca

[lyle]

On Aug 2, 4:42 am, ongaro.ad...@ia o.florence.it wrote:

Hi,
I'm experiencing a strange problem with .mdb files.
We have two buildings connected by optical fiber (a single LAN).
Everything works perfect with any file, any size, any application
software. The hardware has been tested several times. Viruses, trojans
and so on: clean for sure.
The problem is that .mdb files (_only .mdb files_) often don't open,
are very slow, or even get crashed and corrupted.
The weird is that even copying them using the OS (tested with XP SP2,
W2K, Server 2003) also doesn't work.
TCP traffic analysis using a sniffer reveals a huge mess of errors:
segments lost, duplicate ACKs, retransmission, etc. Impossible to
understand what's happening.
Did anyone ever experienced something similar?

Luca

What are you doing with the mdb file?
Copying it?
Linking to it from another mdb file?
Opening one (perhaps the only) instance of it living on the "server"
from various clients? (Most, maybe all developers I know very strongly
DIS-recommend this, recommending that each user have his or her own
copy of a front end mdb, linked to a backend data mdb living on the
server instead; I have no experience with the single front end myself,
the notion of setting things up that way never having occured to me.)
I apologize if you are feeling like saying, "Don't patronize me!"
right now, but sometimes we need to point these things out when we're
not familiar with a poster's level of expertise.
Using it as a library?

Copying them doesn't work? If you rename them from "filename.m db" to
"filename.d at" do they copy OK then?

You're quite sure there are no problems with the network. I expect
there are not. But in the computer world I'm never 100% sure about
anything, ever. That makes it just like the rest of my world.

[ongaro.admin]

On 2 Ago, 15:02, lyle <lyle.fairfi... @gmail.comwrote :

On Aug 2, 4:42 am, ongaro.ad...@ia o.florence.it wrote:

Hi,
I'm experiencing a strange problem with .mdb files.
We have two buildings connected by optical fiber (a single LAN).
Everything works perfect with any file, any size, any application
software. The hardware has been tested several times. Viruses, trojans
and so on: clean for sure.
The problem is that .mdb files (_only .mdb files_) often don't open,
are very slow, or even get crashed and corrupted.
The weird is that even copying them using the OS (tested with XP SP2,
W2K, Server 2003) also doesn't work.
TCP traffic analysis using a sniffer reveals a huge mess of errors:
segments lost, duplicate ACKs, retransmission, etc. Impossible to
understand what's happening.
Did anyone ever experienced something similar?

Luca

What are you doing with the mdb file?
Copying it?
Linking to it from another mdb file?
Opening one (perhaps the only) instance of it living on the "server"
from various clients? (Most, maybe all developers I know very strongly
DIS-recommend this, recommending that each user have his or her own
copy of a front end mdb, linked to a backend data mdb living on the
server instead; I have no experience with the single front end myself,
the notion of setting things up that way never having occured to me.)
I apologize if you are feeling like saying, "Don't patronize me!"
right now, but sometimes we need to point these things out when we're
not familiar with a poster's level of expertise.
Using it as a library?

Copying them doesn't work? If you rename them from "filename.m db" to
"filename.d at" do they copy OK then?

You're quite sure there are no problems with the network. I expect
there are not. But in the computer world I'm never 100% sure about
anything, ever. That makes it just like the rest of my world.

You welcome patronizing me. I'll do the same in my case. But I'm fifty
years old, started with networks in early 80's.
We had this problem since longtime, I'm dedicating me to solve it
right now that most of the crew is on holidays, so I'm sure that there
is little traffic, no locks, etc. So I'm talking about _any_ .mdb
files, even new and empty, not used as libraries or whatever, etc. I
did spent a lot of time in checking every switch and transceiver in
the middle, but apparently the network is sane (in fact, all other
files flash through).
I tried renaming it, but the result is the same. I tried any
combination of server, client and OS. I tried also to do the test
using a laptop, moving it from one building to another, and the
problem is: .mdb files with the fiber optic in the middle.

Thinking about calling Harry Potter...

[Tom van Stiphout]

On Thu, 2 Aug 2007 13:41:16 +0100, "Baz"
<ba**@REMOVEbca p.THEeuro1net.C APScomwrote:

Could it be that an AntiVirus program would treat mdb files
differently?
But then the same would happen with similar size xls files.

-Tom.

>I don't believe for a minute that the file system treats mdb files any
differently to any other file. If you get these TCP/IP problems
file-copying mdb files then you are sure to be getting them when copying any
similar-sized file between the same two locations.

Of course, if users have the file open when you are copying it who knows
what disasters might ensue...

<on**********@ iao.florence.it wrote in message
news:11******* *************** @g4g2000hsf.goo glegroups.com.. .

>On Aug 2, 11:00 am, Salad <o...@vinegar.c omwrote:

ongaro.ad...@ia o.florence.it wrote:
Hi,
I'm experiencing a strange problem with .mdb files.
We have two buildings connected by optical fiber (a single LAN).
Everything works perfect with any file, any size, any application
software. The hardware has been tested several times. Viruses, trojans
and so on: clean for sure.
The problem is that .mdb files (_only .mdb files_) often don't open,
are very slow, or even get crashed and corrupted.
The weird is that even copying them using the OS (tested with XP SP2,
W2K, Server 2003) also doesn't work.
TCP traffic analysis using a sniffer reveals a huge mess of errors:
segments lost, duplicate ACKs, retransmission, etc. Impossible to
understand what's happening.
Did anyone ever experienced something similar?

Luca

Since it's possible your mdb is partially corrupted...

If everyone is out maybe modify your desktop icon temporarily to
something like
"C:\MSACCESS.EX E" "YourMDBPath.md b" /excl
and then compact it

Modify again and add the decompile switch
"C:\MSACCESS.EX E" "YourMDBPath.md b" /excl /decompile

After decompiled, exit out and go back to
"C:\MSACCESS.EX E" "YourMDBPath.md b" /excl
and enter it and compact it and then recompile the app. Fix any
compiler errors if any.

Check and see if you have proper references. Is everybody up to date on
their service packs (Help/About in MS-Access)

Is your reference to DAO 3.6 and others have a ref to DAO 3.51?

Or perhaps create a new mdb and import all the objects (remember to hit
Options to import menus, etc)

Just some things to check.

Thank you,
but we checked all what you suggested already. The problem persists
also with blank empty new .mdb files.
I forgot to mention that no problems occur inside any of the two
single LAN segments, the trouble is just when crossing the optic
fiber, and only with .mdb files (we tried also to rename them, no
way).
It looks to me more something related to the way the filesystem
handles .mdb files. Apparently, it does it in a different way than
other filetypes, making them dramatically sensitive to small
transmission delays.

Luca

[Salad]

on**********@ia o.florence.it wrote:

On 2 Ago, 15:02, lyle <lyle.fairfi... @gmail.comwrote :

>>On Aug 2, 4:42 am, ongaro.ad...@ia o.florence.it wrote:

>>>Hi,
I'm experiencing a strange problem with .mdb files.
We have two buildings connected by optical fiber (a single LAN).
Everything works perfect with any file, any size, any application
software. The hardware has been tested several times. Viruses, trojans
and so on: clean for sure.
The problem is that .mdb files (_only .mdb files_) often don't open,
are very slow, or even get crashed and corrupted.
The weird is that even copying them using the OS (tested with XP SP2,
W2K, Server 2003) also doesn't work.
TCP traffic analysis using a sniffer reveals a huge mess of errors:
segments lost, duplicate ACKs, retransmission, etc. Impossible to
understand what's happening.
Did anyone ever experienced something similar?

>>>Luca

What are you doing with the mdb file?
Copying it?
Linking to it from another mdb file?
Opening one (perhaps the only) instance of it living on the "server"
from various clients? (Most, maybe all developers I know very strongly
DIS-recommend this, recommending that each user have his or her own
copy of a front end mdb, linked to a backend data mdb living on the
server instead; I have no experience with the single front end myself,
the notion of setting things up that way never having occured to me.)
I apologize if you are feeling like saying, "Don't patronize me!"
right now, but sometimes we need to point these things out when we're
not familiar with a poster's level of expertise.
Using it as a library?

Copying them doesn't work? If you rename them from "filename.m db" to
"filename.dat " do they copy OK then?

You're quite sure there are no problems with the network. I expect
there are not. But in the computer world I'm never 100% sure about
anything, ever. That makes it just like the rest of my world.

You welcome patronizing me. I'll do the same in my case. But I'm fifty
years old, started with networks in early 80's.
We had this problem since longtime, I'm dedicating me to solve it
right now that most of the crew is on holidays, so I'm sure that there
is little traffic, no locks, etc. So I'm talking about _any_ .mdb
files, even new and empty, not used as libraries or whatever, etc. I
did spent a lot of time in checking every switch and transceiver in
the middle, but apparently the network is sane (in fact, all other
files flash through).
I tried renaming it, but the result is the same. I tried any
combination of server, client and OS. I tried also to do the test
using a laptop, moving it from one building to another, and the
problem is: .mdb files with the fiber optic in the middle.

Thinking about calling Harry Potter...

If I were paranoid I'd think there'd be a program sitting around called
ScrewWithMDBs running in memory that would read the headers of any files
being accessed and if they were an MDB, mess them up.

In a throw mud at the wall and hoping something sticks...

What happens if you take a large text file (you could export a large
table to a text file) and rename it to MDB and then filecopy? Same thing?

What happens if you do Run/Command and get to DOS and Copy a file from
DOS instead of Windows?

What happens if you rename a file to .MDA or .MDE?

What happens if you make the file an MDE?

What program is associated with opening an MDB?

Does this occur at all stations or only specific stations?

I would have no idea what the "bare-bones" minimum processes are
required to run Windows but what happens if you close any and all
programs in the start bar and system tray. Close all virus programs.
Close your firewall program. Then test the copy. If problem exists,
CTRL+ALT+DEL and start closing processes with your username 1 by 1 and
test. If problem exists then start closing other services 1 by 1 and
test.

If at this point you still have no success, I'd start looking at the
network, routers, and switches and anything programmable regarding the
network.

[David W. Fenton]

on**********@ia o.florence.it wrote in
news:11******** **************@ g4g2000hsf.goog legroups.com:

I forgot to mention that no problems occur inside any of the two
single LAN segments, the trouble is just when crossing the optic
fiber, and only with .mdb files (we tried also to rename them, no
way).
It looks to me more something related to the way the filesystem
handles .mdb files. Apparently, it does it in a different way than
other filetypes, making them dramatically sensitive to small
transmission delays.

This has been known about Access forever.

There is no reason, however, that the fiber segment should be
different from the wired segment. I had client running a high-speed
fiber network with multiple locations and they had no problems
whatsoever with running their Access apps across that. Of course,
they had the front ends on their local PCs and only the back end was
on the other end of the fiber optic link.

There is something wrong with the fiber network link, and that's
indisputable based on the sniffer report that you mentioned earlier.
Run the same tests on a wired network segment and then take the
results to your IT folks. They should be very concerned about such
an issue.

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