2009-08-19 18 views
0

Ich habe eine (sehr einfache und Standard) UPDATE-Anweisung, die entweder direkt in Query Analyzer funktioniert, oder als gespeicherte Prozedur in Query Analyzer ausgeführt.Microsoft Access ADP UPDATE Abfrage aktualisiert nicht

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 ist, wenn ich die gleiche gespeicherte Prozedur über Microsoft ADP (durch Doppelklick auf dem sproc Namen oder mit der Option Ausführen) ausführen, heißt es „Abfrage erfolgreich ausgeführt wird, aber nicht zurück Aufzeichnungen“ und was nicht Aktualisieren Sie die Datensätze, wenn ich die Tabellen direkt überprüfe.

Bevor jemand sagt "Syntax von MS-Access ist anders als SQLServer T-SQL", denken Sie daran, dass mit ADP alles auf dem Server passiert und man tatsächlich durch T-SQL geht.

Irgendwelche guten Ideen von irgendwelchen ADP-Gurus da draußen?

Antwort

1

Gotcha. Auf meine eigene Frage zum Wohle anderer antworten.

Extras/Optionen/Erweitert/Client-Server-Einstellungen/Standard Max Datensätze ist auf 10.000 festgelegt (vermutlich ist dies die Standardeinstellung). Ändern Sie diesen Wert für unbegrenzt auf 0.

Meine Tabelle hatte mehr als 100.000 Zeilen und was auch immer von 10.000 aktualisiert wurde war schwierig zu finden (unter einem Meer von 90.000 + nicht aktualisierte Zeilen). Daher hat das Update nicht wie erwartet funktioniert.

0

Versuchen Sie zu sehen, ob die Abfrage auf dem SQL Server mit SQL Profiler ausgeführt wird.
Auch ich denke, Sie müssen möglicherweise die verknüpfte Tabelle & schließen Sie es erneut, um die aktualisierten Datensätze zu sehen.

Funktioniert das?

+0

die aktualisierten Datensätze zu sehen, die ich die Tabellen direkt in SQL Server kontrollieren, nicht die verknüpfte ein. Werde später Profiler ausprobieren, da ich es vorher noch nie benutzt habe und etwas Zeit brauche, um es herauszufinden. – joedotnot

-1

Ich scheine mich zu erinnern, dass ich immer die Meldung "Keine Zeilen zurückgeben" erhalten habe und die Nachrichten einfach ausschalten musste. Es ist weil es keine Zeilen zurückgibt!

wie für die andere - manchmal gibt es ein Problem mit dem primären Schlüssel. Hat die aktualisierte Tabelle einen Primärschlüssel in SQLServer? Wenn ja, überprüfen Sie die Ansicht der Tabelle in Access - manchmal kommt dieser Link nicht durch. Es ist schon eine Weile her, also könnte ich mich irren, aber ich denke, Sie müssen sich vielleicht die Entwurfsansicht der Tabelle ansehen, während Sie Zugriff haben, und dort den Primärschlüssel hinzufügen.

EDIT: Zusätzlicher Gedanke: in Ihrem Debugging, werfen Sie in Print-Anweisungen, um zu sehen, was die Werte Ihrer Eingaben sind. Nimmt es tatsächlich die Daten aus der Tabelle ab, wie Sie es erwarten, wenn Sie vom Zugriff ausführen?

+0

Autonummer ist nicht das Problem. Die PK-Idee ist ein guter Gedanke, aber nicht für eine ADP-Abfrage. – JohnFx

+0

Ich denke, du hast Recht - es ist keine automatische Nummer. Aber ich erinnere mich klar, dass der Primärschlüssel ein Problem sein könnte. Obwohl es keinen Unterschied macht, wenn ein gespeicherter Proc einfach ausgeführt wird, frage ich mich, ob das Problem mit dem primären Schlüssel immer noch ein Problem sein könnte, wenn die Ausführung aus der Zugriffsumgebung heraus ausgeführt wird. Wenn ich es wäre, würde ich das überprüfen, nur um sicherzugehen, bevor ich nach etwas suchte, was ein obskurer Käfer sein könnte. – user158017

+0

Ich ignorierte die msg "no records returned" msg, ich wusste, dass es eine Updateabfrage war, ich hätte mir mehr Aufmerksamkeit gewidmet, wenn es "no rows affected" gesagt hätte. Mein Beispiel deutete an, dass ich mich den Primärschlüsseln pk1, pk2 anschließe. Und nein, sie sind keine autonumber/identity-Spalten. – joedotnot

0

Führen Sie die Abfrage mit SQL PRofiler ausgeführt. Bevor Sie die Ablaufverfolgung starten, fügen Sie alle Fehlerereignisse hinzu. Dadurch erhalten Sie Fehler, die der SQL Server generiert, dass der Access ADP möglicherweise nicht korrekt (oder überhaupt) angezeigt wird.

Fühlen Sie sich frei, sie hier zu veröffentlichen.

+0

Ich habe Profiler mit allen Fehler und Warnung eingeschaltet. Abgesehen von einer Reihe von Anweisungen, die anzeigen, dass die Abfrage ausgeführt wird (SP: Starting, SQL: StmtStarting, SQL: StmtCompleted, SP: Completed) und einige Dauer, scheint nichts als ein Fehler zu stehen! Zumindest kann ich bestätigen, dass die Anfrage den richtigen Server trifft! – joedotnot

+0

ok, das ist also ein Schritt in die richtige Richtung. Das sagt uns, dass wir den SQL Server treffen und dass die gespeicherte Prozedur ohne Probleme ausgeführt wird (zumindest soweit der SQL Server weiß). Aber dann rollt die Access-Datenbank aus irgendeinem Grund die Transaktion zurück. Es ist lange her, seit ich im Bereich Access arbeite. Gibt es eine Möglichkeit, etwas Debug-Code in die SQL-Prozedur zu schreiben und zu sehen, ob man nicht sehen kann, ob etwas irgendwo auf der Linie steht? – mrdenny