468,514 Members | 1,626 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,514 developers. It's quick & easy.

.mdb and TCP - weird problem

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

Aug 2 '07 #1
20 1882
on**********@iao.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.EXE" "YourMDBPath.mdb" /excl
and then compact it

Modify again and add the decompile switch
"C:\MSACCESS.EXE" "YourMDBPath.mdb" /excl /decompile

After decompiled, exit out and go back to
"C:\MSACCESS.EXE" "YourMDBPath.mdb" /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.

Aug 2 '07 #2
On Aug 2, 11:00 am, Salad <o...@vinegar.comwrote:
ongaro.ad...@iao.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.EXE" "YourMDBPath.mdb" /excl
and then compact it

Modify again and add the decompile switch
"C:\MSACCESS.EXE" "YourMDBPath.mdb" /excl /decompile

After decompiled, exit out and go back to
"C:\MSACCESS.EXE" "YourMDBPath.mdb" /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

Aug 2 '07 #3

<on**********@iao.florence.itwrote in message
news:11**********************@w3g2000hsg.googlegro ups.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.
Aug 2 '07 #4
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**********@iao.florence.itwrote in message
news:11**********************@g4g2000hsf.googlegro ups.com...
On Aug 2, 11:00 am, Salad <o...@vinegar.comwrote:
ongaro.ad...@iao.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.EXE" "YourMDBPath.mdb" /excl
and then compact it

Modify again and add the decompile switch
"C:\MSACCESS.EXE" "YourMDBPath.mdb" /excl /decompile

After decompiled, exit out and go back to
"C:\MSACCESS.EXE" "YourMDBPath.mdb" /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

Aug 2 '07 #5
On Aug 2, 4:42 am, ongaro.ad...@iao.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.mdb" 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.

Aug 2 '07 #6
On 2 Ago, 15:02, lyle <lyle.fairfi...@gmail.comwrote:
On Aug 2, 4:42 am, ongaro.ad...@iao.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.mdb" 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...

Aug 2 '07 #7
On Thu, 2 Aug 2007 13:41:16 +0100, "Baz"
<ba**@REMOVEbcap.THEeuro1net.CAPScomwrote:

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.itwrote in message
news:11**********************@g4g2000hsf.googlegr oups.com...
>On Aug 2, 11:00 am, Salad <o...@vinegar.comwrote:
ongaro.ad...@iao.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.EXE" "YourMDBPath.mdb" /excl
and then compact it

Modify again and add the decompile switch
"C:\MSACCESS.EXE" "YourMDBPath.mdb" /excl /decompile

After decompiled, exit out and go back to
"C:\MSACCESS.EXE" "YourMDBPath.mdb" /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
Aug 2 '07 #8
on**********@iao.florence.it wrote:
On 2 Ago, 15:02, lyle <lyle.fairfi...@gmail.comwrote:
>>On Aug 2, 4:42 am, ongaro.ad...@iao.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.mdb" 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.


Aug 2 '07 #9
on**********@iao.florence.it wrote in
news:11**********************@g4g2000hsf.googlegro ups.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/
Aug 2 '07 #10
on**********@iao.florence.it wrote in
news:11**********************@q75g2000hsh.googlegr oups.com:
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).
Are you sure there isn't a router or switch somewhere on the fiber
network segment that's got firewall or AV software running on it?

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Aug 2 '07 #11
Salad <oi*@vinegar.comwrote in
news:13*************@corp.supernews.com:
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?
If it really is the filename that's correlated with the problem, you
might try naming your back end MDB with some other extension, like
DAT or something, and see if that gets the packets through
unmangled.

There really is something wrong with your network -- there's no
question of that. But it's not likely to be a hardware issue per se
so much as some kind of software that's mucking around with the
packets as they pass through some point in the chain of devices on
the fiber optic segment.

If you run the same TCP traffic analysis on a wired segment and get
no reports of problems, that's really proof that your networking
people need to figure out what's wrong with the fiber segment.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Aug 2 '07 #12
Hi Ongaro,

I am not sure if this is useful to you or not, but I have heard that
there are some 'advanced' network switching devices that try to play
'smart' with some types of application data. I am sure that there are
many marketing names for such a 'technology' so I am not sure what it
might be called in your switches, but it may be worth having a look at
the specifications for the switches and see if they are trying to
implement this type of 'smarts'.

Just a thought

Cheers

The Frog

Aug 3 '07 #13
On 2 Ago, 21:30, "David W. Fenton" <XXXuse...@dfenton.com.invalid>
wrote:
Salad <o...@vinegar.comwrote innews:13*************@corp.supernews.com:
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?

If it really is the filename that's correlated with the problem, you
might try naming your back end MDB with some other extension, like
DAT or something, and see if that gets the packets through
unmangled.

There really is something wrong with your network -- there's no
question of that. But it's not likely to be a hardware issue per se
so much as some kind of software that's mucking around with the
packets as they pass through some point in the chain of devices on
the fiber optic segment.

If you run the same TCP traffic analysis on a wired segment and get
no reports of problems, that's really proof that your networking
people need to figure out what's wrong with the fiber segment.

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

- I stopped all the AVs and firewalls
- anything I rename to .MDB passes fast, regardless data type and
filesize;
- any extension I rename .MDB to: same problem;
- converting in .MDE has no effect;
- copying from DOS prompt: the same;
- this happens from any station in LAN1 to any station in LAN2, and
viceversa;
- no problem inside the LAN segments.

I am also convinced that the problem should reside somewhere in middle
of the network.
Of course it's my own problem and not a Microsoft flaw, as mine is not
the only fiber LAN in the world.
But WHY THE HELL only with .MDB files?
Why TCP traffic analysis shows problems only with them?
What do they have different from any other file?
Aug 3 '07 #14
On 3 Ago, 09:38, ongaro.ad...@iao.florence.it wrote:
On 2 Ago, 21:30, "David W. Fenton" <XXXuse...@dfenton.com.invalid>
wrote:
Salad <o...@vinegar.comwrote innews:13*************@corp.supernews.com:
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?
If it really is the filename that's correlated with the problem, you
might try naming your back end MDB with some other extension, like
DAT or something, and see if that gets the packets through
unmangled.
There really is something wrong with your network -- there's no
question of that. But it's not likely to be a hardware issue per se
so much as some kind of software that's mucking around with the
packets as they pass through some point in the chain of devices on
the fiber optic segment.
If you run the same TCP traffic analysis on a wired segment and get
no reports of problems, that's really proof that your networking
people need to figure out what's wrong with the fiber segment.
--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

Thank you all.

- I stopped all the AVs and firewalls
- anything I rename to .MDB passes fast, regardless data type and
filesize;
- any extension I rename .MDB to: same problem;
- converting in .MDE has no effect;
- copying from DOS prompt: the same;
- this happens from any station in LAN1 to any station in LAN2, and
viceversa;
- no problem inside the LAN segments.

I am also convinced that the problem should reside somewhere in middle
of the network.
Of course it's my own problem and not a Microsoft flaw, as mine is not
the only fiber LAN in the world.
But WHY THE HELL only with .MDB files?
Why TCP traffic analysis shows problems only with them?
What do they have different from any other file?
I just forgot to mention that I also tried copying from Linux to Linux
(using SMB), getting the same problem...

Aug 3 '07 #15
On 3 Ago, 09:38, ongaro.ad...@iao.florence.it wrote:
On 2 Ago, 21:30, "David W. Fenton" <XXXuse...@dfenton.com.invalid>
wrote:
Salad <o...@vinegar.comwrote innews:13*************@corp.supernews.com:
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?
If it really is the filename that's correlated with the problem, you
might try naming your back end MDB with some other extension, like
DAT or something, and see if that gets the packets through
unmangled.
There really is something wrong with your network -- there's no
question of that. But it's not likely to be a hardware issue per se
so much as some kind of software that's mucking around with the
packets as they pass through some point in the chain of devices on
the fiber optic segment.
If you run the same TCP traffic analysis on a wired segment and get
no reports of problems, that's really proof that your networking
people need to figure out what's wrong with the fiber segment.
--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

Thank you all.

- I stopped all the AVs and firewalls
- anything I rename to .MDB passes fast, regardless data type and
filesize;
- any extension I rename .MDB to: same problem;
- converting in .MDE has no effect;
- copying from DOS prompt: the same;
- this happens from any station in LAN1 to any station in LAN2, and
viceversa;
- no problem inside the LAN segments.

I am also convinced that the problem should reside somewhere in middle
of the network.
Of course it's my own problem and not a Microsoft flaw, as mine is not
the only fiber LAN in the world.
But WHY THE HELL only with .MDB files?
Why TCP traffic analysis shows problems only with them?
What do they have different from any other file?
I just forgot to mention that I also tried copying from Linux to Linux
(using SMB), getting the same problem...

Aug 3 '07 #16
On 3 Ago, 09:38, ongaro.ad...@iao.florence.it wrote:
On 2 Ago, 21:30, "David W. Fenton" <XXXuse...@dfenton.com.invalid>
wrote:
Salad <o...@vinegar.comwrote innews:13*************@corp.supernews.com:
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?
If it really is the filename that's correlated with the problem, you
might try naming your back end MDB with some other extension, like
DAT or something, and see if that gets the packets through
unmangled.
There really is something wrong with your network -- there's no
question of that. But it's not likely to be a hardware issue per se
so much as some kind of software that's mucking around with the
packets as they pass through some point in the chain of devices on
the fiber optic segment.
If you run the same TCP traffic analysis on a wired segment and get
no reports of problems, that's really proof that your networking
people need to figure out what's wrong with the fiber segment.
--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

Thank you all.

- I stopped all the AVs and firewalls
- anything I rename to .MDB passes fast, regardless data type and
filesize;
- any extension I rename .MDB to: same problem;
- converting in .MDE has no effect;
- copying from DOS prompt: the same;
- this happens from any station in LAN1 to any station in LAN2, and
viceversa;
- no problem inside the LAN segments.

I am also convinced that the problem should reside somewhere in middle
of the network.
Of course it's my own problem and not a Microsoft flaw, as mine is not
the only fiber LAN in the world.
But WHY THE HELL only with .MDB files?
Why TCP traffic analysis shows problems only with them?
What do they have different from any other file?
I just forgot to mention that I also tried copying from Linux to Linux
(using SMB), getting the same problem...

Aug 3 '07 #17
On 3 Ago, 09:38, ongaro.ad...@iao.florence.it wrote:
On 2 Ago, 21:30, "David W. Fenton" <XXXuse...@dfenton.com.invalid>
wrote:
Salad <o...@vinegar.comwrote innews:13*************@corp.supernews.com:
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?
If it really is the filename that's correlated with the problem, you
might try naming your back end MDB with some other extension, like
DAT or something, and see if that gets the packets through
unmangled.
There really is something wrong with your network -- there's no
question of that. But it's not likely to be a hardware issue per se
so much as some kind of software that's mucking around with the
packets as they pass through some point in the chain of devices on
the fiber optic segment.
If you run the same TCP traffic analysis on a wired segment and get
no reports of problems, that's really proof that your networking
people need to figure out what's wrong with the fiber segment.
--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

Thank you all.

- I stopped all the AVs and firewalls
- anything I rename to .MDB passes fast, regardless data type and
filesize;
- any extension I rename .MDB to: same problem;
- converting in .MDE has no effect;
- copying from DOS prompt: the same;
- this happens from any station in LAN1 to any station in LAN2, and
viceversa;
- no problem inside the LAN segments.

I am also convinced that the problem should reside somewhere in middle
of the network.
Of course it's my own problem and not a Microsoft flaw, as mine is not
the only fiber LAN in the world.
But WHY THE HELL only with .MDB files?
Why TCP traffic analysis shows problems only with them?
What do they have different from any other file?
I just forgot to mention that I also tried copying from Linux to Linux
(using SMB), getting the same problem...

Aug 3 '07 #18
On 3 Ago, 09:38, ongaro.ad...@iao.florence.it wrote:
On 2 Ago, 21:30, "David W. Fenton" <XXXuse...@dfenton.com.invalid>
wrote:
Salad <o...@vinegar.comwrote innews:13*************@corp.supernews.com:
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?
If it really is the filename that's correlated with the problem, you
might try naming your back end MDB with some other extension, like
DAT or something, and see if that gets the packets through
unmangled.
There really is something wrong with your network -- there's no
question of that. But it's not likely to be a hardware issue per se
so much as some kind of software that's mucking around with the
packets as they pass through some point in the chain of devices on
the fiber optic segment.
If you run the same TCP traffic analysis on a wired segment and get
no reports of problems, that's really proof that your networking
people need to figure out what's wrong with the fiber segment.
--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

Thank you all.

- I stopped all the AVs and firewalls
- anything I rename to .MDB passes fast, regardless data type and
filesize;
- any extension I rename .MDB to: same problem;
- converting in .MDE has no effect;
- copying from DOS prompt: the same;
- this happens from any station in LAN1 to any station in LAN2, and
viceversa;
- no problem inside the LAN segments.

I am also convinced that the problem should reside somewhere in middle
of the network.
Of course it's my own problem and not a Microsoft flaw, as mine is not
the only fiber LAN in the world.
But WHY THE HELL only with .MDB files?
Why TCP traffic analysis shows problems only with them?
What do they have different from any other file?
I just forgot to mention that I also tried copying from Linux to Linux
(using SMB), getting the same problem...

Aug 3 '07 #19
on**********@iao.florence.it wrote in
news:11*********************@22g2000hsm.googlegrou ps.com:
I just forgot to mention that I also tried copying from Linux to
Linux (using SMB), getting the same problem...
That just proves that there's a hardware device somewhere between
LAN1 and LAN2 that's sniffing packets and doing something to them.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Aug 3 '07 #20
Sounds like you are copying open access database files which work in
99% of cases.

The solution to your problem might be to split your databases and move
the back end tables into SQL Server or SQL Express.

This is indicated, not by the number of users, but rather the network.

There are probably some other solutions, like replication so as to
totally avoid the LAN issue, although it is more likely a switch
trying to be too smart....Try copy large files from different pcs over
the lan and see what the sniffer picks up.....

Depending on the application, there might be a few tricks to employ as
well.

Regards,
Tom Bizannes
Sydney, Australia
http://www.smartbiz.com.au

Aug 6 '07 #21

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

3 posts views Thread by redneck_kiwi | last post: by
6 posts views Thread by Unicorn | last post: by
1 post views Thread by Jeffrey Melloy | last post: by
reply views Thread by Zwyatt | last post: by
1 post views Thread by Strange Cat | last post: by
reply views Thread by P Pulkkinen | last post: by
reply views Thread by NPC403 | last post: by
1 post views Thread by fmendoza | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.