Sql – Microsoft Access ADP UPDATE Query does NOT update

adpms-accesstsql

I have a (very simple and standard) UPDATE statement which works fine either directly in Query Analyser, or executed as a stored procedure in Query Analyser.

UPDATE A
SET 
      A.field1 = B.col1
    , A.field2 = B.col2
FROM
       tblA AS A INNER JOIN tblB AS B 
ON A.pk1 = B.pk1 AND A.pk2 = B.pk2

Problem is when i execute the same stored proc via microsoft ADP (by double-clicking on the sproc name or using the Run option), it says "query ran successfully but did not return records" AND does NOT update the records when i inspect the tables directly.

Before anyone even says "syntax of MS-Access is different than SQLServer T-SQL", remember that with ADP everything happens on the server and one is actually passing thru to T-SQL.

Any bright ideas from any ADP gurus out there?

Best Answer

Gotcha. Responding to my own question for the benefit of anyone else.

Tools / Options / Advanced / Client-Server Settings / Default max records is set at 10,000 (presumably this is the default). Change this to 0 for unlimited.

My table had 100,000+ rows and whatever set of 10,000 it was updating was difficult to find ( among a sea of 90,000+ un-updated rows ). Hence the update did not work fully as expected.

Related Solutions

Sql – Parameter Sniffing (or Spoofing) in SQL Server

FYI - you need to be aware of something else when you're working with SQL 2005 and stored procs with parameters.

SQL Server will compile the stored proc's execution plan with the first parameter that's used. So if you run this:

usp_QueryMyDataByState 'Rhode Island'

The execution plan will work best with a small state's data. But if someone turns around and runs:

usp_QueryMyDataByState 'Texas'

The execution plan designed for Rhode-Island-sized data may not be as efficient with Texas-sized data. This can produce surprising results when the server is restarted, because the newly generated execution plan will be targeted at whatever parameter is used first - not necessarily the best one. The plan won't be recompiled until there's a big reason to do it, like if statistics are rebuilt.

This is where query plans come in, and SQL Server 2008 offers a lot of new features that help DBAs pin a particular query plan in place long-term no matter what parameters get called first.

My concern is that when you rebuilt your stored proc, you forced the execution plan to recompile. You called it with your favorite parameter, and then of course it was fast - but the problem may not have been the stored proc. It might have been that the stored proc was recompiled at some point with an unusual set of parameters and thus, an inefficient query plan. You might not have fixed anything, and you might face the same problem the next time the server restarts or the query plan gets recompiled.

SQL update query using joins

UPDATE im
SET mf_item_number = gm.SKU --etc
FROM item_master im
JOIN group_master gm
    ON im.sku = gm.sku 
JOIN Manufacturer_Master mm
    ON gm.ManufacturerID = mm.ManufacturerID
WHERE im.mf_item_number like 'STA%' AND
      gm.manufacturerID = 34

To make it clear... The UPDATE clause can refer to an table alias specified in the FROM clause. So im in this case is valid

Generic example

UPDATE A
SET foo = B.bar
FROM TableA A
JOIN TableB B
    ON A.col1 = B.colx
WHERE ...

Best Answer

Related Solutions

Sql – Parameter Sniffing (or Spoofing) in SQL Server

SQL update query using joins

Generic example

Related Topic