Tag Info

New answers tagged

0

If I inherit a database and try to hunt down where DML is coming from, I usually right click the database in SSMS and use the 'Generate Scripts...' menu option and then select Stored procedures and UDFs to be scripted. You can save it in a file or into a new query window and then do a string search for your table. You should also check any link server ...


2

What I did MariaDB [test]> select version(); +---------------------+ | version() | +---------------------+ | 10.0.15-MariaDB-log | +---------------------+ 1 row in set (0.00 sec) Are you using 5.5? CREATE TABLE terms_of_use ( id int(11) NOT NULL AUTO_INCREMENT PRIMARY KEY, current_version varchar(20), last_updated timestamp, ...


1

It's always possible that this script is populated by something external to the database instance that the table is situated on - from an application, via a linked server, from a script on the server. There are probably other possibilities but you get the idea. The best way I can think to track activity on the table is to run SQL Server Profiler (via the ...


1

Index statistics should tell you when the table was last updated, so maybe it really has been just populated once. Of course you could for example add a trigger to the table to track of someone inserts / updates it, but don't forget to remove it later.


0

It sounds like the user that's executing the ALTER TABLE and the user who's running SHOW PROCESSLIST are not the same user, and the second user lacks the PROCESS privilege. If you have the PROCESS privilege, you can see all threads. Otherwise, you can see only your own threads (that is, threads associated with the MySQL account that you are using). ...


2

I suspect that there's a database error that you're not seeing here. If you remove the GO statement right before the two final UPDATE statements, I'd imagine that the query crashes with something like "unknown column 'group_id'". This happens because an execution plan is generated for each batch at a time, i.e. every time you pass GO. In my experience, ...


1

GO (Transact-SQL) Signals the end of a batch of Transact-SQL statements to the SQL Server utilities. RETURN (Transact-SQL) Exits unconditionally from a query or procedure. RETURN is immediate and complete and can be used at any point to exit from a procedure, batch, or statement block. Statements that follow RETURN are not executed. When ...



Top 50 recent answers are included