Hi ktm400,

No, it's not. The only change from the previous posting is that you
added a PRIMARY KEY constraint on the IDENTITY column. That means that
you still don't have any real keys: a key on an IDENTITY will never
prevent the accidental duplicate insertion of data.

All other points mentioned yesterday by David also still apply.

So we have (quoted almost verbatim from David's message):

* No other keys than identity = no integrity

* The numbered columns 1-10 look like what's usually called a Repeating
Group. Repeating groups are a fundamentally bad design for lots of
important reasons.

* "Counter", "Date" and "Time" are pretty useless column names. They
tell us virtually nothing about the attributes in question. Names are
important, don't neglect them.

* Why two CHAR columns for date and time? Why not DATETIME?

* Do you know the difference between exact and inexact numeric datatypes
and are you sure you want to use inexact numerics for all the Readings?

* Why BIGINT for the IDENTITY column?  Do you expect 10^19 rows! Chances
are INTEGER will be more than sufficient.

And to this list, I'd like to add:

* No CHECK constraint for any of the columns. Though I know nothing
aboput the field of business you're in, I have a hunch that at least the
columns Blow and BlowDetectorOn should allow only a limited set of
values. Also, would you really want to accept data with MaxThickness
less than MinThickness? Or with TargetThickness not somewhere between
those two?

* No FOREIGN KEY constraints. I think that BlankID is intended to refer
to data in another column, but without FOREIGN KEY constraint, it's very
unlikely that it will really do so.

Please read some basic books on database design before proceeding.
Building a database is like building a home: you can attempt to do it
without ever learning how to lay bricks, and you might even build
something that looks like a house - but it'll probably all come tumbling
down the moment you slam a door.

Best, Hugo