views:

85

answers:

3

I'm inserting new rows into a SQLite table, but I don't want to insert duplicate rows.

I also don't want to specify every column in the database if possible. I don't even know if this is possible.

I should be able to take my values and create a new row with them, but if they duplicate another row they should either overwrite the existing row or do nothing.

A: 

http://www.sqlite.org/lang_insert.html

insert or replace might interest you

Andrey
+1  A: 

Your desires appear mutually contradictory. While Andrey's insert or replace answer will get you close to what say you want, what should probably clarify for yourself what you really want.

If you don't want to specify every column, and you want a (presumably) partial row to update rather than insert, you should probably look at the unique constraint and know that the ambiguity of your requirements was also made by the SQL92 Committee.

msw
+1  A: 

This is one of the very first steps in database design and normalization. You have to be able to explicitly define what you mean by a duplicate row, and then place a primary key constraint, (or a unique constraint), on the columns in your table that represent that definition.

Before you can define what duplicate means, you have to define (or decide) exactly what the table is to contain,. i.e., what real-world business domain entity or abstraction each row in the table represents, or will hold data for...

Once you have done this, the PK or unique constraint will stop you from inserting duplicate rows... The same PK will help you find the duplicate row when it does exist, and update it with the values of the non-duplicate-defining (non-PK) columns that are different from the values in the existing duplicate row. Only after all this has been done, can an insert or replace (as defined by SQL Lite) process help. This command checks whether a duplicate row (*as dedined by yr PK constraint) exists, and if it does, instead of inserting a new row, it updates the non-PK defined columns in that row with the values spplied by your Replace query.

Charles Bretana
or one could just avoid thinking about design and use the first thing that can be hacked into working and then be puzzled in six months as to why the first implementation is so brittle and resistant to maintenance, blame "the DBM" and move on to the next job... ;)
msw