Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.databases.ms-sqlserver > #1159

Re: Memory Stick Reliability Issue

From rja.carnegie@gmail.com
Newsgroups comp.databases.ms-sqlserver
Subject Re: Memory Stick Reliability Issue
Date 2012-07-02 03:53 -0700
Organization http://groups.google.com
Message-ID <243a1129-b1cc-4db1-94dc-181b2d981996@googlegroups.com> (permalink)
References <5jalq7lbf7f0drnih4vdae1cdl17g2sh7g@4ax.com> <566f9bf9-fb03-4351-a8cd-28858c84d9f6@e20g2000vbm.googlegroups.com>

Show all headers | View raw


On Monday, June 25, 2012 2:32:16 PM UTC+1, Philipp Post wrote:
> I usually test my memory sticks with a software called H2TESTW if I
> have doubt if they are still good.
> http://translate.google.ca/translate?hl=en&sl=de&u=http://www.heise.de/software/download/h2testw/50539&sa=X&oi=translate&resnum=2&ct=result&prev=/search%3Fq%3DH2testw%26hl%3Den%26sa%3DG
> 
> It writes the USB stick full of test data, tries to read them and
> reports in case of error. If that is the case you will need to get a
> new one.
> 
> Then, on a FAT32 formatted stick (what is the default), the maximum
> file size is 4 GB for one file.

That may be not the problem in this case - 
the installation files apparently aren't that 
big - but I have found that Windows or CMD
error messages are unhelpful in that case.
It says something about an error on the
destination disk, which of course is healthy.

The COPY statement within CMD has an optional
switch /V "Verifies that new files are written 
correctly", which presumably means that they 
can be read back.  But perhaps best to FC 
(compare) the original and copy.  /V might
only rely on the sector checksum code on hard 
disk and floppy disk storage, which a USB drive 
presumably doesn't have, or it would not give
you the defective file, it would say something
like "Error reading disc, Abort Retry Fail?"

By the way, our technicians invented a wonderful
new program for transferring database backups
between servers - just like replication, except 
that we invented it ourselves!  Unfortunately,
it took some time to discover that once in a 
zillion bytes, just a few bytes together were 
corrupted - and that SQL Server 2005 evidently
doesn't have a checksum for that, either.
(So, obviously, we should.  Obviously.  Zip, say.)
It appeared as occasional wrong data values 
in the restored databases, as errors detected
by a thorough DBCC CHECKDB, and finally in a 
byte-for-byte comparison of original file and
copy.

The current state of play is that we are 
moving files internally between servers
using FTP ... how /are/ things for you,
up there in the twenty-first century?
Page me!  Or send a fax!  It's so so lonely...
On the plus side, here in the last century, 
people still use Usenet!

Back to comp.databases.ms-sqlserver | Previous | NextPrevious in thread | Find similar


Thread

Memory Stick Reliability Issue Gene Wirchenko <genew@ocis.net> - 2012-05-09 10:37 -0700
  Re: Memory Stick Reliability Issue Jeroen Mostert <jmostert@xs4all.nl> - 2012-05-09 20:44 +0200
    Re: Memory Stick Reliability Issue Gene Wirchenko <genew@ocis.net> - 2012-05-09 12:50 -0700
      Re: Memory Stick Reliability Issue Jeroen Mostert <jmostert@xs4all.nl> - 2012-05-09 22:18 +0200
        Re: Memory Stick Reliability Issue Gene Wirchenko <genew@ocis.net> - 2012-05-09 13:31 -0700
  Re: Memory Stick Reliability Issue Tony Toews <ttoews@telusplanet.net> - 2012-05-09 13:59 -0600
    Re: Memory Stick Reliability Issue Gene Wirchenko <genew@ocis.net> - 2012-05-09 13:35 -0700
      Re: Memory Stick Reliability Issue Tony Toews <ttoews@telusplanet.net> - 2012-05-09 21:42 -0600
  Re: Memory Stick Reliability Issue Philipp Post <post.philipp@googlemail.com> - 2012-06-25 06:32 -0700
    Re: Memory Stick Reliability Issue rja.carnegie@gmail.com - 2012-07-02 03:53 -0700

csiph-web