Windows ftp corrupts MS Access databases

[TCook]

Hello All,

I just wanted to let everyone know about this issue we encountered as
developers last week.

We had used the ftp functionality available from the command line in Windows
XP Pro to download source code and associated MS Access databases. We could
not use the database and kept receiving the error "Invalid database
format...".

We thought it may have been the version of Office so we upgraded to Office
2003. It didn't work. We found other information online regarding repair,
etc. Running MS Access repair didn't work.

Finally, we obtained FileZilla from the Mozilla website, downloaded the
files again and the databases worked fine.

The ftp download from Windows corrupted the files.

If anyone else experiences such behavior, try using another ftp application
first rather than last.

Best Regards,

TC

 

[Danny J. Lesandrini]

My first guess was that the file wasn't being downloaded completely,
and your alternate download test suggests that was the problem. It's
not an Access question, but a Windows question.

 

[Karl Strausser]

Do not use Windows FTP for SERIOUS uploading work. You found
FileZilla, there is WS-FTP, and many other FREE professional tools.

Karl

Hello All,

I just wanted to let everyone know about this issue we encountered as
developers last week.

We had used the ftp functionality available from the command line in
Windows
XP Pro to download source code and associated MS Access databases. We
could
not use the database and kept receiving the error "Invalid database
format...".

We thought it may have been the version of Office so we upgraded to
Office
2003. It didn't work. We found other information online regarding
repair,
etc. Running MS Access repair didn't work.

Finally, we obtained FileZilla from the Mozilla website, downloaded
the
files again and the databases worked fine.

The ftp download from Windows corrupted the files.

If anyone else experiences such behavior, try using another ftp
application
first rather than last.

Best Regards,

TC

 

[Yves Leclerc]

Hello All,

I just wanted to let everyone know about this issue we encountered as
developers last week.

We had used the ftp functionality available from the command line in Windows
XP Pro to download source code and associated MS Access databases. We could
not use the database and kept receiving the error "Invalid database
format...".

We thought it may have been the version of Office so we upgraded to Office
2003. It didn't work. We found other information online regarding repair,
etc. Running MS Access repair didn't work.

Finally, we obtained FileZilla from the Mozilla website, downloaded the
files again and the databases worked fine.

The ftp download from Windows corrupted the files.

If anyone else experiences such behavior, try using another ftp application
first rather than last.

Best Regards,

TC

The command line ftp has several different options that can be set for the
file transfer. Unfortunately, one option it does not have is to check, and
set, the transfer mode (Binary or ASCII) automatically, which FileZilla has
set to "automatic."

 

[Albert D.Kallal]

Did you execute a binary command before doing the transfer?

Golly....going back to the old cpm days...you even had to execute the binary
command....

If you don't, then your file will not be transferred intact.....

I used ftp and ms-access files for years now...never a problem......

 

[Haggis]

Did you execute a binary command before doing the transfer?

Golly....going back to the old cpm days...you even had to execute the
binary command....

If you don't, then your file will not be transferred intact.....

I used ftp and ms-access files for years now...never a problem......

--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
(e-mail address removed)
http://www.members.shaw.ca/AlbertKallal

ooohhh you're from Canada! do you know John?

LOL sorry couldn't resist :>

David
Dartmouth,N.S. , Canada

 

[Tim Slattery]

Did you execute a binary command before doing the transfer?

Golly....going back to the old cpm days...you even had to execute the binary
command....

If you don't, then your file will not be transferred intact.....

More precisely, if you don't set binary mode, the file will be
transferred in ASCII mode. That means that CRs will be translated to
CR/LF, as you would want to happen if you were transferring a text
file. Transferring a database file that way is guaranteed to produce
gibberish.

 

[Enkidu]

Hello All,

I just wanted to let everyone know about this issue we encountered as
developers last week.

We had used the ftp functionality available from the command line in Windows
XP Pro to download source code and associated MS Access databases. We could
not use the database and kept receiving the error "Invalid database
format...".

We thought it may have been the version of Office so we upgraded to Office
2003. It didn't work. We found other information online regarding repair,
etc. Running MS Access repair didn't work.

Finally, we obtained FileZilla from the Mozilla website, downloaded the
files again and the databases worked fine.

The ftp download from Windows corrupted the files.

If anyone else experiences such behavior, try using another ftp application
first rather than last.

I'd back up Albert's suggestion. From the command line you need to issue
the 'binary' command to successfully download non-text files (actually I
think that it is non-ASCII files). I remember having to do this using
unix ftp commandline commands.

Cheers,

Cliff

 

[HK]

Transferring the file as a zip file will keep you from having to set
binary?? A question I ask because I've been using Windows FTP from the
command line and the browser and been having more success that way than
I did using gMail. gMail was causing me corruption. I'm still trying
to understand gmail's attachment sending rules. My friend sent me a
database in .mdb format and it worked fine. But when I try to send a
..mdb in a zip file, it get's rejected because gmail sees it as an
executable file and won't allow it to be sent for security reasons. So
I started renaming the .zip file to a .txt file and then they got
corrupted.

 

[TC]

Zip files are binary files.

If you rename a zip file to txt, maybe it gets transferred in text mode
(not binary), thereby corrupting it.

HTH,
TC (MVP Access)
http://tc2.atspace.com

 

[Tim Slattery]

Transferring the file as a zip file will keep you from having to set
binary??

Definitely not! A zip is a binary file. Sending it via FTP in ASCII
mode will corrupt it.

A question I ask because I've been using Windows FTP from the
command line and the browser and been having more success that way than
I did using gMail. gMail was causing me corruption. I'm still trying
to understand gmail's attachment sending rules. My friend sent me a
database in .mdb format and it worked fine.

Email is very different from FTP. An email client - including gmail -
will encode an attachment so that it can pass through Internet email
systems which are guaranteed to pass 7-bit characters, not 8-bit. This
encoding system results in increasing the size of the attachment
somewhat, and has nothing to with FTP's binary/ASCII modes. If you
email a Unix text file (end-of-line is CR only) to a Windows user
(end-of-line is CR LF), no translation will be done, and if the
Windows user views the file in an editor that can't handle the Unix
EOL convention, it will look strange. Transmitting the same file
between the same clients using FTP in ASCII mode will result in a file
on the Windows platform using the proper EOL convention.

But when I try to send a .mdb in a zip file, it get's rejected because gmail sees it as an
executable file and won't allow it to be sent for security reasons.

Many email systems refuse to transmit executables or zips these days.

So I started renaming the .zip file to a .txt file and then they got
corrupted.

When it was received and renamed on the other end, the contents of the
ZIP couldn't be extracted? That seems odd to me. If your recipient
simply used his default mechanism to open the *.txt file, he would
surely get gibberish.

 

[aaron.kempf]

more importantly

MS ACCESS CORRUPTS ACCESS FILES

if you care enough to build a database don't use a piece of crap
database 'engine'

 

[HK]

Hey, give me a break. We don't all need enterprise solutions to hold a
few thousand records. Licensing fees alone would send most of us back
to paper on your professional grade "database 'engine'"'s. I realize
there are some exceptions to the cost issue, (MSDE, SQL Server Express,
etc.) but they tend to be just a little more complex than using Jet. I
feel no need to argue furthur.

Tim Slattery:
The contents could be extracted but the .mdb could not be opened.

One thing that isn't real clear to me, I've been using the command line
in XP Home to do some of my FTP transfers. I don't specify the mode as
binary; I simply "get filename.zip" and everything works beautiful.
This is contrary to many of the posts here. Is there something I'm
missing? Does the FTP server specify the transfer mode?

 

[Tim Slattery]

Hey, give me a break. We don't all need enterprise solutions to hold a
few thousand records. Licensing fees alone would send most of us back
to paper on your professional grade "database 'engine'"'s. I realize
there are some exceptions to the cost issue, (MSDE, SQL Server Express,
etc.) but they tend to be just a little more complex than using Jet. I
feel no need to argue furthur.

Tim Slattery:
The contents could be extracted but the .mdb could not be opened.

One thing that isn't real clear to me, I've been using the command line
in XP Home to do some of my FTP transfers. I don't specify the mode as
binary; I simply "get filename.zip" and everything works beautiful.
This is contrary to many of the posts here. Is there something I'm
missing? Does the FTP server specify the transfer mode?

No, the client does. Some clients have an "automatic" mode where
they'll look at the extension of the file and try to figure the proper
mode from that. The built-in command-line client is not that
sophisticated.

If the transfer is between two similar machines (both are running
Windows, for example), then I don't think it will matter. It's when
one machine is UNIX and the other is Windows that the ASCII mode can
mess up binary files. That's because Unix and Windows signal
end-of-line in text files in different ways, and ASCII mode tries to
translate the end-of-line characters during the transfer. If the file
being transferred really isn't ASCII, that translation will change
something that doesn't need to be changed.

 

[aaron.kempf]

you ALL do need a better database; MDB is crap

MSDE is **FREE** and it's not more complex; it is 100 times more
POWERFUL.

Aren't you tired of rebooting your fileservers and bouncing your
webserver?

MDB is utter crap; they blame 'wireless networking corrupts access' and
'ftp corrupts access'

the bottom line is that MDB is crap; and anyone that is still using it
should be fired.

go find yourself some SQL Server kid; coming out of high school for
christ sakes-- Access Data Projects are just flat out 10 times more
powerful.

AND THEY'RE NOT MORE COMPLEX.

Sprocs and Views-- using ADP-- these are the most beautiful things in
the world.

MDB is for sissies as are people that write MDBs

 

[Tony Toews]

Aren't you tired of rebooting your fileservers and bouncing your
webserver?

Never had to reboot file servers due to Access.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm

 

[aaron.kempf]

then obviously im doing something wrong.

you've got a dozen users of a mdb frontend / backend (gag)

everyone exits out; you disconnect the server from the network; and it
still doesn't release the lock

you open up the LDB with the jet utilities?

what do you do?

i've worked for 30 clients in the past 10 years that each had more than
a dozen mdb files; and sometimes jet just flakes out and the only way
to get the LDB file released is to reboot the fileserver.

that is but one reason that MDB is a total and complete waste of time--
rebooting a file server is NEVER an acceptable gamble.

how many times have you had POS MDB linked table locking screw up your
SQL Server?

how many times have you made clients reboot their desktops when jet
starts acting up?

it just blows my mind that you sit there and claim that 'things are
peachy with mdb'


MDB against SQL is the most inefficient technology anywhere.

and MDB against MDB just isn't reliable enough for me to even make a
database to keep track of when im porking your wife.

MDB just isn't reliable enough for a single user and a single record;
anything above and beyond that-- the developer is liable for loss of
data.

MDB you can't even secure; i mean DUH?

if you care enough to be building a database; use a real database
backend.

MDB is a waste of time
and MDB developers are a waste of resources.

never use MDB for anything; not for a single record, not for a single
user.

and ESPECIALLY never across any type of network.


-Aaron

-Aaron