473,320 Members | 1,580 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,320 software developers and data experts.

.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 2091
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 thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

3
by: redneck_kiwi | last post by:
Hi all: I have a really weird problem. I am developing a customer catalog system for my company and as such have delved into sessions for authentication and access levels. So far, I have managed...
13
by: Wolfgang Kaml | last post by:
Hello All, I have been researching newsgroups and knowledgebase all morning and not found a solution that would solve the problem I have. I am having an ASP or ASPX web page that implement a...
1
by: Kaneda | last post by:
Hello everyone! I have some weird(?) problems, and I am not quite sure if there are due to my errors or maybe a limitation in the .Net framework. I have a ComboBox I need to fill with the...
0
by: Kaneda | last post by:
Hello everyone! I have some weird(?) problems, and I am not quite sure if there are due to my errors or maybe a limitation in the .Net framework. I have a ComboBox I need to fill with the...
6
by: Unicorn | last post by:
I can only say this is a weird problem! I will be sitting there typing away in the code window, when the whole IDE just vanishes without a trace. I get no error messages and no indication, it...
1
by: Jeffrey Melloy | last post by:
I recently noticed that in my web app, a \n wasn't getting converted to a <br />. (The problem turned out to be that for this particular record, it was a \r). When I checked out the record in...
0
by: Zwyatt | last post by:
having a really weird little bug w/ time_t...check it out: I have the following code (simplified here): #include <time.h> class A { public: char *aString; int aNum;
1
by: Strange Cat | last post by:
Hi everyone! I have a weird problem with FormsAuthentication. I have an app that works just fine with FormsAuthentication. The user requests the homepage, he is redirected to login page,...
3
by: aling | last post by:
Execute following T-SQL within Queary Analyzer of SQL Server 2000: ======================================= DECLARE @dTest DATETIME SET @dTest='2001-1-1 1:1:1:991' SELECT @dTest SET...
0
by: P Pulkkinen | last post by:
Dear all, sorry, i know this code is far little too long to debug here, but there is really annoying logical error. If someone debugs this, I really offer warm virtual handshake. What this...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
1
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.