Tag Info

New answers tagged

3

update a set a.CHK = 1 from tableA a join tableB b on b.IDA = a.IDA and b.IDB = a.IDB


1

It could also be that you applied the update to SQL Server but didn't apply it to other services (SSAS, SSRS, etc.) or to other components (like Management Tools). Run SP2 again (or SP3!) and see which components it finds eligible for an update - I bet there is at least one.


2

By any chance are multiple instances of SQL Server running on this host machine? Check the Services console to see if more than one service of SQL Server is running. If so, the newly discovered one may be running the older service pack.


1

It's a case-sensitivity issue. "dateType" including the quotes is a quoted identifier, which implies that it retains its case (as opposed to an unquoted identifier which is implicitly converted to lower case). Quoted identifiers allows other columns of the same table named for instance "DateType" or "datetype" or other variants that differ only by case (not ...


0

This works - I had the JOIN wrong UPDATE `events` INNER JOIN `plays_in_events` ON (`plays_in_events`.`EventID` = `events`.`EventID`) INNER JOIN `plays` ON (`plays_in_events`.`PlayID` = `plays`.`PlayID`) SET events.Name = plays.Play WHERE events.Name IS NULL and plays_in_events.PlayID = 1 and the earlier comments were quite right, but it took me ...


1

Well, you are running this giant UPDATE statement of all rows in table B: update B t1 set b1 = t2.a1 from (select b1, b2 from B) t2 where t1.a2 = t2.b2; which will more-or-less double the size of the table, since the UPDATE has to keep old row versions around. You may want to read up a bit on how PostgreSQL implements MVCC and how vacuuming works, but to ...


2

The WRITE method is minimally logged. If you use regular UPDATE statement, it would result in overwriting the entire string using FULL LOGGING. This would become inefficient when dealing with large updates. To support update for large value data types, the UPDATE syntax supports .WRITE method. This will result in less Transaction log due to its nature of ...


1

Until we see the actual code, we can only speculate but for what is worth, I'll do a guess. Assuming that your code involves only a table and its columns (no @variables involved) and is something like: UPDATE tablename SET column_a = column_b, column_b = 0 WHERE (condition) ; It is valid SQL and 100% correct. Correct, meaning that ...


0

It sounds like you're asking whether it's possible to alter a trigger in an atomic operation, where, if the new definition fails, you don't lose the old one... similar to CREATE OR REPLACE VIEW, which replaces the view definition if the new definition is valid, but leaves the old one in place, if you can't replace it. Unfortunately, there's no ALTER ...


1

You can do this by querying pg_stat_activity on newer PostgreSQL versions that record the query start time. See pg_stat_activity in the PostgreSQL manual. Use pg_cancel_backend to cancel the query, or pg_terminate_backend to close the connection running the query. However, I strongly recommend that you instead fix the problem so that your queries don't ...


0

If your base accumulates rapidly incoming inserts, the good idea is to split long-lasting query into the sequence of small queries. That prevents DB from connections shortage when the connections are wait for the table will be unlocked and new connection being refused and data is being lost. Then you'll get the execution queue like <uiiiuiii... ...


1

When update executed once it's guaranteed that all rows that satisfy conditions will be updated (or none in case of error). 4 separate updates may update different rows (something may change between updates, and you're using MyIsam, so transactions won't help; in addition, your update depends on non-deterministic NOW() ). Another point is that each ...



Top 50 recent answers are included