InnoDB best practices for ensuring unique tuple where one column can be NULL

2009-04-16 Thread Lev Lvovsky
hello, assume the following table: CREATE TABLE t ( id INT UNSIGNED auto_increment PRIMARY KEY, c1 INT UNSIGNED NOT NULL, c2 INT UNSIGNED NOT NULL, c3 INT UNSIGNED, UNIQUE (c1, c2, c3) ) engine = InnoDB; Our first issue is that the UNIQUE constraint on (c1,c2,c3) does not work in the case tha

which duplicate key was hit on last insert?

2007-11-12 Thread Lev Lvovsky
We have tables in our database that, in addition to primary key constraints also have unique() constraints of several columns in the table: CREATE TABLE Test ( COL1INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, COL2VARCHAR(10) NOT NULL, COL3VARCHAR(10) NOT NULL,

Re: which duplicate key was hit on last insert?

2007-11-13 Thread Lev Lvovsky
On Nov 13, 2007, at 1:25 AM, yaya sirima wrote: Hi, CREATE TABLE Test ( COL1INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, COL2VARCHAR(10) NOT NULL, COL3VARCHAR(10) NOT NULL, UNIQUE(COL2, COL3); --(not that) FULLTEXT(col1,col2) );

view irregularities

2008-02-11 Thread Lev Lvovsky
I'm running into a difficult to reproduce problem with a view which is similar to the following: CREATE TABLE Common ( COMMON_ID INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, COMMON_NAME VARCHAR(50), UNIQUE(COMMON_NAME) ) ENGINE = InnoDB; CREATE TABLE Parent ( PARENT_ID

Re: view irregularities

2008-02-14 Thread Lev Lvovsky
Shawn, On Feb 13, 2008, at 9:12 AM, Shawn Green wrote: Lev Lvovsky wrote: I'm running into a difficult to reproduce problem with a view which is similar to the following: CREATE TABLE Common ( COMMON_ID INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, COMMON_NAME VARCH

external updates/additions of database entries

2007-01-12 Thread Lev Lvovsky
Hello, I'm looking for help in merging the contents of two database tables with identical columns between them. A base set of data will be stored in the "permanent" table, and incremental additions and/or changes will be introduced in the "staging" table the ID's of the data in the tables

case sensitivity in stored procedure formal arguments

2007-02-28 Thread Lev Lvovsky
Could someone explain the logic of how case sensivity works on stored procedure formal argument names? Example: CREATE PROCEDURE sp_Test ( IN col1 INT, IN col2 INT ) BEGIN INSERT INTO Table SET COL1 = col1, COL2 = col2; END We've found that this is problem

"on duplicate key" question

2007-02-28 Thread Lev Lvovsky
This is somewhat related to my last question RE conflicting procedure argument names, but in regards to multi-row inserts... suppose the following procedure: DROP PROCEDURE IF EXISTS sp_ImportedUpdate | CREATE PROCEDURE sp_ImportedUpdate () DETERMINISTIC CONTAINS SQL MODIFIES SQL DATA BEGI