news:1157578420.373154.312080@m79g2000cwm.googlegroups.com...
>I am working on a SQL Server database in which there are no primary
> keys set on the tables.  I can tell what they are using for a key.  It
> is usually named ID, has a data type of int and does not allow nulls.
> However, since it is not set as a primary key you can create a
> duplicate key.
>
> This whole thing was created by someone who is long gone.  I don't
> know how long I will be here and I don't want to break anything.  I
> just want to work with things the way they are.
>
> So if I want to insert a new record, and I want the key, which  is
> named ID, to be the next number in the sequence, is there something  I
> can do in an insert sql statement to do this?
>

"Andrew Petrochuk [MSFT]" <andrew.petroc***@microsoft.com> wrote in message
news:%23lqQI1f0GHA.1040@TK2MSFTNGP06.phx.gbl...
> You can use MAX function to get maximum and use next number.
>
> select MAX(Id) from T
>
> --
>
> This posting is provided "AS IS" with no warranties, and confers no
> rights.
>
>
> <tomca***@gmail.com> wrote in message
> news:1157578420.373154.312080@m79g2000cwm.googlegroups.com...
>>I am working on a SQL Server database in which there are no primary
>> keys set on the tables.  I can tell what they are using for a key.  It
>> is usually named ID, has a data type of int and does not allow nulls.
>> However, since it is not set as a primary key you can create a
>> duplicate key.
>>
>> This whole thing was created by someone who is long gone.  I don't
>> know how long I will be here and I don't want to break anything.  I
>> just want to work with things the way they are.
>>
>> So if I want to insert a new record, and I want the key, which  is
>> named ID, to be the next number in the sequence, is there something  I
>> can do in an insert sql statement to do this?
>>
>

> >> What exactly is the difference between a record in an ISAM file and a  row in SQL <<
>
> I changed your question a bit. Like most new ideas, the hard part of
> understanding what the relational model is comes in un-learning what
> you know about file systems.  As Artemus Ward (William Graham Sumner,
> 1840-1910) put it, "It ain't so much the things we don't know that get
> us into trouble. It's the things we know that just ain't so."
>
> If you already have a background in data processing with traditional
> file systems, the first things to un-learn are:
>
>  (0) Databases are not file sets.
>  (1) Tables are not files.
>  (2) Rows are not records.
>  (3) Columns are not fields.
>
> Modern data processing began with punch cards.  The influence of the
> punch card lingered on long after the invention of magnetic tapes and
> disk for data storage.  This is why early video display  terminals were
> 80 columns across.  Even today, files which were migrated from cards to
> magnetic tape files or disk storage still use 80 column records.
>
> But the influence was not just on the physical side of data processing.
>  The methods for handling data from the prior media were imitated in
> the new  media.
>
> Data processing first consisted of sorting and merging decks of punch
> cards (later, sequential magnetic tape files) in a series of distinct
> steps.  The result of each step feed into the next step in the process.
>  This leads to temp table and other tricks to mimic that kind of
> processing.
>
> Relational databases do not work that way.  Each user connects to the
> entire database all at once, not to one file at time in a sequence of
> steps.  The users might not all have the same database access rights
> once they are connected, however.  Magnetic tapes could not be shared
> among users at the same time, but shared data is the point of a
> database.
>
> Tables versus Files
>
> A file is closely related to its physical storage media.  A table may
> or may  not be a physical file.  DB2 from IBM uses one file per table,
> while Sybase puts several entire databases inside one file.  A table is
> a <i>set<i> of rows of the same kind of thing.  A set has no ordering
> and it makes no sense to ask for the first or last row.
>
> A deck of punch cards is sequential, and so are magnetic tape files.
> Therefore, a <i>physical<i> file of ordered sequential records also
> became the <i>mental<i> model for data processing and it is still hard
> to shake.  Anytime you look at data, it is in some physical ordering.
>
> The various access methods for disk storage system came later, but even
> these access methods could not shake the mental model.
>
> Another conceptual difference is that a file is usually data that deals
> with a whole business process.  A file has to have enough data in
> itself to support applications for that business process.  Files tend
> to be "mixed"  data which can be described by the name of the business
> process, such as "The Payroll file" or something like that.
>
> Tables can be either entities or relationships within a business
> process.  This means that the data which was held in one file is often
> put into several tables.  Tables tend to be "pure" data which can be
> described by single words.  The payroll would now have separate tables
> for timecards, employees, projects and so forth.
>
> Tables as Entities
>
> An entity is physical or conceptual "thing" which has meaning be
> itself.  A  person, a sale or a product would be an example.  In a
> relational database, an entity is defined by its attributes, which are
> shown as values in columns in rows in a table.
>
> To remind users that tables are sets of entities, I like to use
> collective or plural nouns that describe the function of the entities
> within the system for the names of tables.  Thus "Employee" is a bad
> name because it is singular; "Employees" is a better name because it is
> plural; "Personnel" is best because it is collective and does not
> summon up a mental picture of individual persons.
>
> If you have tables with exactly the same structure, then they are sets
> of the same kind of elements.  But you should have only one set for
> each kind of data element!  Files, on the other hand, were PHYSICALLY
> separate units of storage which could be alike -- each tape or disk
> file represents a step in the PROCEDURE , such as moving from raw data,
> to edited data, and finally to archived data.  In SQL, this should be a
> status flag in a table.
>
> Tables as Relationships
>
> A relationship is shown in a table by columns which reference one or
> more entity tables.  Without the entities, the relationship has no
> meaning, but the relationship can have attributes of its own.  For
> example, a show  business contract might have an agent, an employer and
> a talent.  The method of payment is an attribute of the contract
> itself, and not of any of the three parties.
>
> Rows versus Records
>
> Rows are not records.  A record is defined in the application program
> which reads it; a row is defined in the database schema and not by a
> program at all.  The name of the field in the READ or INPUT statements
> of the application; a row is named in the database schema. Likewise,
> the PHYSICAL order of the field names in the READ statement is vital
> (READ a,b,c is not the same as READ c, a, b; but SELECT a,b,c is the
> same data as SELECT c, a, b.
>
> All empty files look alike; they are a directory entry in the operating
> system with a name and a length of zero bytes of storage.  Empty tables
> still have columns, constraints, security privileges and other
> structures, even tho they have no rows.
>
> This is in keeping with the set theoretical model, in which the empty
> set is a perfectly good set.  The difference between SQL's set model
> and standard mathematical set theory is that set theory has only one
> empty set, but in SQL  each table has a different structure, so they
> cannot be used in places where non-empty versions of themselves could
> not be used.
>
> Another characteristic of rows in a table is that they are all alike in
> structure and they are all the "same kind of thing" in the model.  In a
> file system, records can vary in size, datatypes and structure by
> having flags in the data stream that tell the program reading the data
> how to interpret it.  The most common examples are Pascal's variant
> record, C's struct syntax and Cobol's OCCURS clause.
>
> The OCCURS keyword in Cobol and the Variant records in Pascal have a
> number which tells the program how many time a record structure is to
> be repeated in the current record.
>
> Unions in 'C' are not variant records, but variant mappings for the
> same physical memory. For example:
>
> union x {int ival; char j[4];} myStuff;
>
> defines myStuff to be either an integer (which are 4 bytes on most
> modern C  compilers, but this code is non-portable) or an array of 4
> bytes, depending on whether you say myStuff.ival or myStuff.j[0];
>
> But even more than that, files often contained records which were
> summaries of subsets of the other records -- so called control break
> reports.  There is no requirement that the records in a file be related
> in any way -- they are literally a stream of binary data whose meaning
> is assigned by the program reading them.
>
> Columns versus Fields
>
> A field within a record is defined by the application program that
> reads it.  A column in a row in a table is defined by the database
> schema.  The datatypes in a column are always scalar.
>
> The order of the application program variables in the READ or INPUT
> statements is important because the values are read into the program
> variables in that order.  In SQL, columns are referenced only by their
> names.  Yes, there are shorthands like the SELECT * clause and INSERT
> INTO <table name> statements which expand into a list of column names
> in the physical order in which the column names appear within their
> table declaration, but these are shorthands which resolve to named
> lists.
>
> The use of NULLs in SQL is also unique to the language.  Fields do not
> support a missing data marker as part of the field, record or file
> itself.  Nor do fields have constraints which can be added to them in
> the record, like the DEFAULT and CHECK() clauses in SQL.
>
> Relationships among tables within a database
>
> Files are pretty passive creatures and will take whatever an
> application program throws at them without much objection.  Files are
> also independent of each other simply because they are connected to one
> application program at a time and therefore have no idea what other
> files looks like.
>
> A database actively seeks to maintain the correctness of all its data.
> The methods used are triggers, constraints and declarative referential
> integrity.
>
> Declarative referential integrity (DRI) says, in effect, that data in
> one table has a particular relationship with data in a second (possibly
> the same)  table.  It is also possible to have the database change
> itself via referential actions associated with the DRI.
>
> For example, a business rule might be that we do not sell products
> which are not in inventory.  This rule would be enforce by a REFERENCES
> clause on the Orders table which references the Inventory table and a
> referential action of ON DELETE CASCADE
>
> Triggers are a more general way of doing much the same thing as DRI.  A
>  trigger is a block of procedural code which is executed before, after
> or instead of an INSERT INTO or UPDATE statement.  You can do anything
> with a trigger that you can do with DRI and more.
>
> However, there are problems with TRIGGERs.  While there is a standard
> syntax  for them in the SQL-92 standard, most vendors have not
> implemented it.  What they have is very proprietary syntax instead.
> Secondly, a trigger cannot pass information to the optimizer like DRI.
> In the example in this section, I know that for every product number in
> the Orders table, I have that same product number in the Inventory
> table.  The optimizer can use that information in setting up EXISTS()
> predicates and JOINs in the queries.  There is no reasonable way to
> parse procedural trigger code to determine this relationship.
>
> The CREATE ASSERTION statement in SQL-92 will allow the database to
> enforce conditions on the entire database as a whole.  An ASSERTION is
> not like a CHECK() clause, but the difference is subtle.  A CHECK()
> clause is executed when there are rows in the table to which it is
> attached.  If the table is empty then all CHECK() clauses are
> effectively TRUE.  Thus, if we wanted to be sure that the Inventory
> table is never empty, and we wrote:
>
>  CREATE TABLE Inventory
>  ( ...
>   CONSTRAINT inventory_not_empty
>        CHECK ((SELECT COUNT(*) FROM Inventory) > 0), ... );
>
> it would not work.  However, we could write:
>
>  CREATE ASSERTION Inventory_not_empty
>         CHECK ((SELECT COUNT(*) FROM Inventory) > 0);
>
> and we would get the desired results.  The assertion is checked at the
> schema level and not at the table level.

>
> I changed your question a bit. Like most new ideas, the hard part of
> understanding what the relational model is comes in un-learning what
> you know about file systems.  As Artemus Ward (William Graham Sumner,
> 1840-1910) put it, "It ain't so much the things we don't know that get
> us into trouble. It's the things we know that just ain't so."
>
> If you already have a background in data processing with traditional
> file systems, the first things to un-learn are:
>
>  (0) Databases are not file sets.
>  (1) Tables are not files.
>  (2) Rows are not records.
>  (3) Columns are not fields.
>
> Modern data processing began with punch cards.  The influence of the
> punch card lingered on long after the invention of magnetic tapes and
> disk for data storage.  This is why early video display  terminals were
> 80 columns across.  Even today, files which were migrated from cards to
> magnetic tape files or disk storage still use 80 column records.
>
> But the influence was not just on the physical side of data processing.
>  The methods for handling data from the prior media were imitated in
> the new  media.
>
> Data processing first consisted of sorting and merging decks of punch
> cards (later, sequential magnetic tape files) in a series of distinct
> steps.  The result of each step feed into the next step in the process.
>  This leads to temp table and other tricks to mimic that kind of
> processing.
>
> Relational databases do not work that way.  Each user connects to the
> entire database all at once, not to one file at time in a sequence of
> steps.  The users might not all have the same database access rights
> once they are connected, however.  Magnetic tapes could not be shared
> among users at the same time, but shared data is the point of a
> database.
>
> Tables versus Files
>
> A file is closely related to its physical storage media.  A table may
> or may  not be a physical file.  DB2 from IBM uses one file per table,
> while Sybase puts several entire databases inside one file.  A table is
> a <i>set<i> of rows of the same kind of thing.  A set has no ordering
> and it makes no sense to ask for the first or last row.
>
> A deck of punch cards is sequential, and so are magnetic tape files.
> Therefore, a <i>physical<i> file of ordered sequential records also
> became the <i>mental<i> model for data processing and it is still hard
> to shake.  Anytime you look at data, it is in some physical ordering.
>
> The various access methods for disk storage system came later, but even
> these access methods could not shake the mental model.
>
> Another conceptual difference is that a file is usually data that deals
> with a whole business process.  A file has to have enough data in
> itself to support applications for that business process.  Files tend
> to be "mixed"  data which can be described by the name of the business
> process, such as "The Payroll file" or something like that.
>
> Tables can be either entities or relationships within a business
> process.  This means that the data which was held in one file is often
> put into several tables.  Tables tend to be "pure" data which can be
> described by single words.  The payroll would now have separate tables
> for timecards, employees, projects and so forth.
>
> Tables as Entities
>
> An entity is physical or conceptual "thing" which has meaning be
> itself.  A  person, a sale or a product would be an example.  In a
> relational database, an entity is defined by its attributes, which are
> shown as values in columns in rows in a table.
>
> To remind users that tables are sets of entities, I like to use
> collective or plural nouns that describe the function of the entities
> within the system for the names of tables.  Thus "Employee" is a bad
> name because it is singular; "Employees" is a better name because it is
> plural; "Personnel" is best because it is collective and does not
> summon up a mental picture of individual persons.
>
> If you have tables with exactly the same structure, then they are sets
> of the same kind of elements.  But you should have only one set for
> each kind of data element!  Files, on the other hand, were PHYSICALLY
> separate units of storage which could be alike -- each tape or disk
> file represents a step in the PROCEDURE , such as moving from raw data,
> to edited data, and finally to archived data.  In SQL, this should be a
> status flag in a table.
>
> Tables as Relationships
>
> A relationship is shown in a table by columns which reference one or
> more entity tables.  Without the entities, the relationship has no
> meaning, but the relationship can have attributes of its own.  For
> example, a show  business contract might have an agent, an employer and
> a talent.  The method of payment is an attribute of the contract
> itself, and not of any of the three parties.
>
> Rows versus Records
>
> Rows are not records.  A record is defined in the application program
> which reads it; a row is defined in the database schema and not by a
> program at all.  The name of the field in the READ or INPUT statements
> of the application; a row is named in the database schema. Likewise,
> the PHYSICAL order of the field names in the READ statement is vital
> (READ a,b,c is not the same as READ c, a, b; but SELECT a,b,c is the
> same data as SELECT c, a, b.
>
> All empty files look alike; they are a directory entry in the operating
> system with a name and a length of zero bytes of storage.  Empty tables
> still have columns, constraints, security privileges and other
> structures, even tho they have no rows.
>
> This is in keeping with the set theoretical model, in which the empty
> set is a perfectly good set.  The difference between SQL's set model
> and standard mathematical set theory is that set theory has only one
> empty set, but in SQL  each table has a different structure, so they
> cannot be used in places where non-empty versions of themselves could
> not be used.
>
> Another characteristic of rows in a table is that they are all alike in
> structure and they are all the "same kind of thing" in the model.  In a
> file system, records can vary in size, datatypes and structure by
> having flags in the data stream that tell the program reading the data
> how to interpret it.  The most common examples are Pascal's variant
> record, C's struct syntax and Cobol's OCCURS clause.
>
> The OCCURS keyword in Cobol and the Variant records in Pascal have a
> number which tells the program how many time a record structure is to
> be repeated in the current record.
>
> Unions in 'C' are not variant records, but variant mappings for the
> same physical memory. For example:
>
> union x {int ival; char j[4];} myStuff;
>
> defines myStuff to be either an integer (which are 4 bytes on most
> modern C  compilers, but this code is non-portable) or an array of 4
> bytes, depending on whether you say myStuff.ival or myStuff.j[0];
>
> But even more than that, files often contained records which were
> summaries of subsets of the other records -- so called control break
> reports.  There is no requirement that the records in a file be related
> in any way -- they are literally a stream of binary data whose meaning
> is assigned by the program reading them.
>
> Columns versus Fields
>
> A field within a record is defined by the application program that
> reads it.  A column in a row in a table is defined by the database
> schema.  The datatypes in a column are always scalar.
>
> The order of the application program variables in the READ or INPUT
> statements is important because the values are read into the program
> variables in that order.  In SQL, columns are referenced only by their
> names.  Yes, there are shorthands like the SELECT * clause and INSERT
> INTO <table name> statements which expand into a list of column names
> in the physical order in which the column names appear within their
> table declaration, but these are shorthands which resolve to named
> lists.
>
> The use of NULLs in SQL is also unique to the language.  Fields do not
> support a missing data marker as part of the field, record or file
> itself.  Nor do fields have constraints which can be added to them in
> the record, like the DEFAULT and CHECK() clauses in SQL.
>
> Relationships among tables within a database
>
> Files are pretty passive creatures and will take whatever an
> application program throws at them without much objection.  Files are
> also independent of each other simply because they are connected to one
> application program at a time and therefore have no idea what other
> files looks like.
>
> A database actively seeks to maintain the correctness of all its data.
> The methods used are triggers, constraints and declarative referential
> integrity.
>
> Declarative referential integrity (DRI) says, in effect, that data in
> one table has a particular relationship with data in a second (possibly
> the same)  table.  It is also possible to have the database change
> itself via referential actions associated with the DRI.
>
> For example, a business rule might be that we do not sell products
> which are not in inventory.  This rule would be enforce by a REFERENCES
> clause on the Orders table which references the Inventory table and a
> referential action of ON DELETE CASCADE
>
> Triggers are a more general way of doing much the same thing as DRI.  A
>  trigger is a block of procedural code which is executed before, after
> or instead of an INSERT INTO or UPDATE statement.  You can do anything
> with a trigger that you can do with DRI and more.
>
> However, there are problems with TRIGGERs.  While there is a standard
> syntax  for them in the SQL-92 standard, most vendors have not
> implemented it.  What they have is very proprietary syntax instead.
> Secondly, a trigger cannot pass information to the optimizer like DRI.
> In the example in this section, I know that for every product number in
> the Orders table, I have that same product number in the Inventory
> table.  The optimizer can use that information in setting up EXISTS()
> predicates and JOINs in the queries.  There is no reasonable way to
> parse procedural trigger code to determine this relationship.
>
> The CREATE ASSERTION statement in SQL-92 will allow the database to
> enforce conditions on the entire database as a whole.  An ASSERTION is
> not like a CHECK() clause, but the difference is subtle.  A CHECK()
> clause is executed when there are rows in the table to which it is
> attached.  If the table is empty then all CHECK() clauses are
> effectively TRUE.  Thus, if we wanted to be sure that the Inventory
> table is never empty, and we wrote:
>
>  CREATE TABLE Inventory
>  ( ...
>   CONSTRAINT inventory_not_empty
>        CHECK ((SELECT COUNT(*) FROM Inventory) > 0), ... );
>
> it would not work.  However, we could write:
>
>  CREATE ASSERTION Inventory_not_empty
>         CHECK ((SELECT COUNT(*) FROM Inventory) > 0);
>
> and we would get the desired results.  The assertion is checked at the
> schema level and not at the table level.
>

"Anith Sen" <an***@bizdatasolutions.com> wrote in message
news:OiFMU%23p0GHA.2036@TK2MSFTNGP05.phx.gbl...
> >> ...if they are told they are incompetent and should not be allowed to
do
> >> their job until they learn the right way.
>
> Not to support reckless rants, but regarding the above statement, that is
> what should be done though, right?  Of course, there are shops that allows
> on the job training assuming all potential risks. But being a
professional,
> isn't it one's obligation to learn the right way before doing his/her job?
>
> None among us would approve of an incompetent doctor practicing medicine
> until they learn the right way. Or an incompetent builder building bridges
> or a bad mechanic fixing cars for that matter. So why is it considered
> offensive in the IT field?
>
> --
> Anith
>
>

"Anith Sen" <an***@bizdatasolutions.com> wrote in message
news:OiFMU%23p0GHA.2036@TK2MSFTNGP05.phx.gbl...
>>> ...if they are told they are incompetent and should not be allowed to do
>>> their job until they learn the right way.
>
> Not to support reckless rants, but regarding the above statement, that is
> what should be done though, right?  Of course, there are shops that allows
> on the job training assuming all potential risks. But being a
> professional, isn't it one's obligation to learn the right way before
> doing his/her job?
>
> None among us would approve of an incompetent doctor practicing medicine
> until they learn the right way. Or an incompetent builder building bridges
> or a bad mechanic fixing cars for that matter. So why is it considered
> offensive in the IT field?
>
> --
> Anith
>

"Anith Sen" <an***@bizdatasolutions.com> wrote in message
news:%237iY6br0GHA.1536@TK2MSFTNGP02.phx.gbl...
>>> Otherwise, we are all 'always' practicing our craft. However, I will
>>> grant that perhaps you too know absolutely everything and do not require
>>> any 'practice'!
>
> Are you pretending to be dumb or a real idiot? Who said anything about
> knowing everything? Are you thick enough to ignore the difference between
> someone wrecking a system without knowing the fundamentals of his trade
> and someone who realize the systemic limitations around him, yet strive to
> be competent?
>
> --
> Anith
>

"Alexander Kuznetsov" <AK_TIREDOFSPAM@hotmail.COM> wrote in message
news:1157738017.901655.239680@b28g2000cwb.googlegroups.com...
> It's actually good that you've mentioned mathematics. In mathematics,
> you choose a set of axioms and use logic to derive your conclusions.
> So, if somebody else chooses a different set of axioms and comes at
> different conclusions, that does not - repeat, not - mean bad
> mathematics.
> A professional mathematician will not call another mathematician a bad
> mathematician if the other one has chosen different axioms,
> used correct logic, and arrived at different conclusions - as long as
> the logic is correct, of course.
> For instance, Lobachevskij had used a set of axioms quite different
> from Euclid's, and Lobachevskij's conclusions were quite different.
> However, AFAIK Lobachevskij has never ever called Euclid a bad
> mathematician.
>
> However I disagree that IT "is a branch of mathematics". I think IT is
> a branch of business that uses applied mathematics. As such,
> different sets of axioms are not equal. For instance, you seem to
> always stick to some axioms such as
> - there must be a middle tier
> - portability is of paramount importance
> and, first of all
> IMO these axioms make perfect sense if it is a big huge enterprise, a
> large corporation. In other cases they may just not apply.
>
> Suppose once in a while I am using a different set of axioms, because
> it better fits my situation at hand, such as
> - expected turnaround (the time between the customer got an idea and
> the solution has been deployed) is one week
> - expected lifespan of the solution is at most 3 months
>
> Suppose I have used waterproof logic and arrived at some conclusions:
> - there will be no middle tier *in this particular case*
> - I will not care about portability *in this particular case*
>
> In mathematics, I am free to choose my set of axioms. As long as my
> logic is correct, my mathematics is just as good as anybody else's.
> Even if my conclusions are, say, non-conformist.
> In business, I am getting a lot of valuable feedback indicating if my
> choice of axioms actually helps my customers make money.
>
> Makes sense?
>

> >Rows are not anything like records; the failure of the first guy to
> >understand this is why he mimiced a magnetic tape file system's record
> >numbers instad of providing a relational key.
>
> I guess I'm showing my age.  I wrote COBOL for the first 20 years of my
> programming life. Old verbal habits change slowly.  But we called them
> records on ISAM files, long after magnetic tape files were obsolete.
>
> What exactly is the difference between a record in an ISAM file and a
> row in a SQL Server database?

>I am working on a SQL Server database in which there are no primary
>keys set on the tables.  I can tell what they are using for a key.  It
>is usually named ID, has a data type of int and does not allow nulls.
>However, since it is not set as a primary key you can create a
>duplicate key.
>
>This whole thing was created by someone who is long gone.  I don't
>know how long I will be here and I don't want to break anything.  I
>just want to work with things the way they are.
>
>So if I want to insert a new record, and I want the key, which  is
>named ID, to be the next number in the sequence, is there something  I
>can do in an insert sql statement to do this?

"tom c" <tomca***@gmail.com> wrote in message
news:1157599354.566386.190220@p79g2000cwp.googlegroups.com...
>I think I am getting in over
> my head.  I was retired and decided to do this because I thought it
> would be interesting and fun.  This was supposed to be a low pressure
> part time job where I set my own hours and do minor enhancements to his
> system.  Now it is a major fix, which could be very high pressure,
> since 40 people are dependent on this thing to work every day if they
> are going to have jobs.   I think I am going to tell him it is too big
> a job for me, and I will help him hire a more skilled full time person.
> Maybe I can still end up working there part time, helping the full
> time person.
>
> The other thing I am wondering about is legal liability.  I am doing
> this as a contractor, not an employee.  I am not a LLC.  I think that
> leaves me open to being sued if he thinks I made his system crash and
> put him out of business.
>

> The legal concern is definitely one to give consideration.
>
> Should you continue, I highly recommend obtaining "Error and Omissions"
> insurance ASAP. As you indicate, the personal risks can be very high.
>
> --
> Arnie Rowland, Ph.D.
> Westwood Consulting, Inc
>
> Most good judgment comes from experience.
> Most experience comes from bad judgment.
> - Anonymous
>
>
> "tom c" <tomca***@gmail.com> wrote in message
> news:1157599354.566386.190220@p79g2000cwp.googlegroups.com...
> >I think I am getting in over
> > my head.  I was retired and decided to do this because I thought it
> > would be interesting and fun.  This was supposed to be a low pressure
> > part time job where I set my own hours and do minor enhancements to his
> > system.  Now it is a major fix, which could be very high pressure,
> > since 40 people are dependent on this thing to work every day if they
> > are going to have jobs.   I think I am going to tell him it is too big
> > a job for me, and I will help him hire a more skilled full time person.
> > Maybe I can still end up working there part time, helping the full
> > time person.
> >
> > The other thing I am wondering about is legal liability.  I am doing
> > this as a contractor, not an employee.  I am not a LLC.  I think that
> > leaves me open to being sued if he thinks I made his system crash and
> > put him out of business.
> >

"tom c" <tomca***@gmail.com> wrote in message
news:1157635713.631092.4540@e3g2000cwe.googlegroups.com...
>I will look into insurance if I continue, but I had thought that a
> contract that said I was not responsible would be enough.
>
>
> Arnie Rowland wrote:
>> The legal concern is definitely one to give consideration.
>>
>> Should you continue, I highly recommend obtaining "Error and Omissions"
>> insurance ASAP. As you indicate, the personal risks can be very high.
>>
>> --
>> Arnie Rowland, Ph.D.
>> Westwood Consulting, Inc
>>
>> Most good judgment comes from experience.
>> Most experience comes from bad judgment.
>> - Anonymous
>>
>>
>> "tom c" <tomca***@gmail.com> wrote in message
>> news:1157599354.566386.190220@p79g2000cwp.googlegroups.com...
>> >I think I am getting in over
>> > my head.  I was retired and decided to do this because I thought it
>> > would be interesting and fun.  This was supposed to be a low pressure
>> > part time job where I set my own hours and do minor enhancements to his
>> > system.  Now it is a major fix, which could be very high pressure,
>> > since 40 people are dependent on this thing to work every day if they
>> > are going to have jobs.   I think I am going to tell him it is too big
>> > a job for me, and I will help him hire a more skilled full time person.
>> > Maybe I can still end up working there part time, helping the full
>> > time person.
>> >
>> > The other thing I am wondering about is legal liability.  I am doing
>> > this as a contractor, not an employee.  I am not a LLC.  I think that
>> > leaves me open to being sued if he thinks I made his system crash and
>> > put him out of business.
>> >
>

> >> The other thing I am wondering about is legal liability.  I am doing  this as a contractor, not an employee.  I am not a LLC.  I think that leaves me open to being sued if he thinks I made his system crash and  put him out of business. <<
>
> My financial services company (USAA) has written $1 Million policies
> for me in such situations.  The only thing they required was that I not
> work on medical systems where human life was involved.
>
> You might also remind them that the boss can go to jail if an audit
> fails.  Let's all hear it for Enron, et al !!

"tom c" <tomca***@gmail.com> wrote in message
news:1157653825.299057.245540@m73g2000cwd.googlegroups.com...
> So what does a $1 Million "Error and Omissions" policy cost?
>
>
>
> --CELKO-- wrote:
>> >> The other thing I am wondering about is legal liability.  I am doing
>> >> this as a contractor, not an employee.  I am not a LLC.  I think that
>> >> leaves me open to being sued if he thinks I made his system crash and
>> >> put him out of business. <<
>>
>> My financial services company (USAA) has written $1 Million policies
>> for me in such situations.  The only thing they required was that I not
>> work on medical systems where human life was involved.
>>
>> You might also remind them that the boss can go to jail if an audit
>> fails.  Let's all hear it for Enron, et al !!
>

"Tony Rogerson" <tonyroger***@sqlserverfaq.com> wrote in message
news:eP52few0GHA.4972@TK2MSFTNGP03.phx.gbl...
>I think you are in the UK Tom?
>
> Check out Professional Indeminity cover - www.insuredrisks.co.uk (Hiscox
> Insurance) for instance; for £250K it cost me £196 a year.
>
> Tony.
>
> --
> Tony Rogerson
> SQL Server MVP
> http://sqlblogcasts.com/blogs/tonyrogerson - technical commentary from a
> SQL Server Consultant
> http://sqlserverfaq.com - free video tutorials
>
>
> "tom c" <tomca***@gmail.com> wrote in message
> news:1157653825.299057.245540@m73g2000cwd.googlegroups.com...
>> So what does a $1 Million "Error and Omissions" policy cost?
>>
>>
>>
>> --CELKO-- wrote:
>>> >> The other thing I am wondering about is legal liability.  I am doing
>>> >> this as a contractor, not an employee.  I am not a LLC.  I think that
>>> >> leaves me open to being sued if he thinks I made his system crash and
>>> >> put him out of business. <<
>>>
>>> My financial services company (USAA) has written $1 Million policies
>>> for me in such situations.  The only thing they required was that I not
>>> work on medical systems where human life was involved.
>>>
>>> You might also remind them that the boss can go to jail if an audit
>>> fails.  Let's all hear it for Enron, et al !!
>>
>
>