Access Backend nach MS SQL überführen, Fragen dazu.

Moderator: ModerationP

Re: Access Backend nach MS SQL überführen, Fragen dazu.

Beitragvon GrandJop » 16. Jan 2018, 09:46

Hallo zusammen

So konnte nun das Problem mit dem Schreibschutz lösen und will meine Erkenntnis auch noch hier reinschreiben:

Den SQLOLEDB muss man explizit als "Data" Provider deklarieren und nicht als Provider als solches, danach sind die Änderungen aduseclient ohne Probleme möglich:

In meinem Modul habe ich somit den Public Const geändert:
alt:
Code: Alles auswählen
Public Const strConnection As String = "Provider=SQLOLEDB;Server=1.1.1.1;Database=Testsystem;Integrated Security=SSPI;"


neu:
Code: Alles auswählen
Public Const strConnection As String = "Provider=Microsoft.Access.OLEDB.10.0;Data Provider=SQLOLEDB;Server=1.1.1.1;Database=Testsystem;Integrated Security=SSPI;"




Gruss
GrandJop
GrandJop
Im Profil kannst Du frei den Rang ändern
 
Beiträge: 188
Registriert: 03. Aug 2016, 15:44

Re: Access Backend nach MS SQL überführen, Fragen dazu.

Beitragvon mmarkus » 16. Jan 2018, 10:50

und was ist bei Verwendung des ServerCursor.

.LockType = adLockOptimistic
.CursorType = adOpenKeyset
.CursorLocation = adUseServer

Schlucken das die Formulare auch.
Wohlgemerkt geht es hier nur um ein Problem der Access Formulare.
Die Recordsets als solches sollte in allen Konstellationen bearbeitbar sein.

LG Markus
ms access what else
mmarkus
Im Profil kannst Du frei den Rang ändern
 
Beiträge: 952
Registriert: 16. Apr 2012, 16:07
Wohnort: Vienna

Re: Access Backend nach MS SQL überführen, Fragen dazu.

Beitragvon GrandJop » 16. Jan 2018, 12:53

Hallo Markus

Was sich bei mir gezeigt hat ist gleich wie oben beschrieben.

Provider = SQLOLEDB
.LockType = adLockOptimistic
.CursorType = adOpenKeyset
.CursorLocation = adUseServer

--> Schreibschutz aktiv in den Formularen

Provider = Microsoft.Access.OLEDB.10.0
Data Provider = SQLOLEDB
.LockType = adLockOptimistic
.CursorType = adOpenKeyset
.CursorLocation = adUseServer

--> Editieren in den Formularen funktioniert einwandfrei

Gruss
GrandJop
GrandJop
Im Profil kannst Du frei den Rang ändern
 
Beiträge: 188
Registriert: 03. Aug 2016, 15:44

Re: Access Backend nach MS SQL überführen, Fragen dazu.

Beitragvon mmarkus » 16. Jan 2018, 13:24

Mit dem Microsoft.Access.OLEDB.10.0 Provider kann man also Server- und ClientCursor beim SQL Server in Verbindung mit Access Forms verwenden.

Danke.
ms access what else
mmarkus
Im Profil kannst Du frei den Rang ändern
 
Beiträge: 952
Registriert: 16. Apr 2012, 16:07
Wohnort: Vienna

Re: Access Backend nach MS SQL überführen, Fragen dazu.

Beitragvon GrandJop » 17. Jan 2018, 10:38

Hallo zusammen

Beim Thema "View" ecke ich noch an der Editierbarkeit an. Sobald in in richtig Join gehe (egal Inner Outer left right)
wird bei mir die View schreibgeschützt, auch wenn ich sie mittels ODBC direkt verknüpfe. Nach ellenlangem Suchen im Google...
... wisst ihr gute Lektüre welche mir die Thematik "ADO <--> View" und allgemein View gut erläutert?

Vielen Dank für eure Mühen. :)

Gruss
GrandJop
GrandJop
Im Profil kannst Du frei den Rang ändern
 
Beiträge: 188
Registriert: 03. Aug 2016, 15:44

Re: Access Backend nach MS SQL überführen, Fragen dazu.

Beitragvon Nouba » 17. Jan 2018, 10:44

Standard bei Views, die mehr als eine Tabelle umfassen, ist, dass sie readonly sind. Ansonsten müsstest Du InsteadOf Trigger für diese Views bereitstellen. Siehe: Verwenden von INSTEAD OF-Triggern
mit freundlichen Grüssen Nouba

Wenn beim Lesen eines Beitrags der Eindruck entsteht, dass sich der Fragesteller wenig Mühe gegeben hat, so erhöht das nicht unbedingt die Motivation, eine Antwort zu verfassen.
Nouba
Im Profil kannst Du frei den Rang ändern
 
Beiträge: 16762
Registriert: 13. Mär 2006, 12:55
Wohnort: Berlin

Re: Access Backend nach MS SQL überführen, Fragen dazu.

Beitragvon Gast » 17. Jan 2018, 12:01

ich bin ja echt kein SQL Profi, aber muss man Views nicht indexieren damit man die Daten bearbeiten kann? so habe ich es bei mir via ODBC-Verknüpfung realisiert. wie man jedoch eine Views über ADODB "bearbeitbar" verknüpft habe ich keine Ahnug.

Gruss
Gast
 

Re: Access Backend nach MS SQL überführen, Fragen dazu.

Beitragvon Bitsqueezer » 17. Jan 2018, 15:50

Hallo,

nein, das ist nicht korrekt. Auch mit Access als Frontend bleibt eine View editierbar, wenn man JOINs benutzt. Man muß aber ein paar Regeln beachten, die nicht immer ganz logisch sind.

a) Ein Index auf eine View ist ein Weg (aber nicht vollständig, auch INSTEAD OF Trigger werden benötigt), eine View updatable zu bekommen, allerdings ist er sehr kompliziert. Um einen (Unique!) Index erstellen zu können, muß man die View an ihr Schema binden. Das hinzubekommen, ist schon sehr fummelig, außerdem bedeutet die Bindung, daß die zugrundeliegenden Tabellen dann nicht mehr im Design geändert werden können, bis die Bindung der View aufgehoben wird. Das alleine ist schon ein Punkt, der diesen Weg für mich zu einem No-Go macht - viel zu kompliziert.
Darüber hinaus muß man für die View einen INSTEAD-OF-Trigger erstellen. Dieser übernimmt dann die INSERT/UPDATE/DELETE-Kommandos und muß dann dafür sorgen, daß alle Daten, die das Frontend übergibt (aus allen beteiligten Tabellen der View) in die richtigen Basistabellen verteilt werden. Um es noch etwas komplizierter zu machen, muß ein Trigger generell so programmiert sein, daß er auch mehr als einen Datensatz verarbeiten kann, wofür SQL Server die beiden virtuellen Tabellen "inserted" and "deleted" in jedem Trigger bereitstellt.

Das ist alles ziemlich aufwendig, daher würde ich diese Methode nur im Notfall verwenden.

b) Zur Korrektur der Aussage von Nouba funktionieren (=bleiben editierbar) auch Views mit JOIN. Was man beachten muß:
  • SQL Server kann immer nur EINE beteiligte Tabelle gleichzeitig verändern. Das ist prinzipiell auch in Access (in den eigenen Tabellen) so, aber Access kann diese UPDATE-Vorgänge intern selbst verteilen, soweit möglich (geht auch nicht immer). Grund ist, daß der UPDATE-Befehl nur eine Tabelle zur Änderung als Parameter entgegennehmen kann, ebenso natürlich INSERT und DELETE.
  • man kann Lookup-Felder statt mit einem JOIN mit einem Sub-SELECT in der SELECT-Feldliste ersetzen, was aufwendiger zu schreiben und u.U. langsamer ist, aber dann die JOINs vermeidet, so daß man nur eine Tabelle in FROM hat, damit bleibt die Abfrage editierbar. In einer Access-Abfrage geht das nur, wenn man statt eines Sub-SELECTs ein DLookup verwendet.
  • da JOINs aber performanter sind, muß man beachten, daß in der Feldliste in jedem Fall das Feld des Primary Keys der Lookup-Tabelle enthalten ist. Wenn man also zwei Tabellen verknüpft hat, muß der PK der zweiten Tabelle in jedem Fall mit in die Feldliste, auch wenn das Frontend diesen gar nicht benötigt. Da man ja z.B. über eine Combobox die ID der Lookup-Tabelle als FK in die erste Tabelle eintragen will, muß dieses Feld natürlich auch in die Feldliste. Den PK der Lookup-Tabelle muß man dann mit einem Aliasnamen versehen, falls diese gleich heißen.
  • Auch hier gilt: Es kann nur eine Tabelle gleichzeitig geändert werden. Wenn man im Frontend also alle Felder beider Tabellen präsentiert und man ändert Daten in Feldern beider Tabellen, wird es eine Fehlermeldung geben. Das Frontend muß immer so gestaltet werden, daß immer nur eine Tabelle in einem Formular geändert werden kann. Das ist i.d.R. immer möglich.

Manchmal ist SQL Server auch anderweitig "zickig" und man muß experimentieren durch einzelnes Herausnehmen von JOINs oder Feldern in der Liste, bis man die Ursache gefunden hat, warum eine Abfrage nicht editierbar ist. Da konnte ich noch keine Logik finden.

Gruß

Christian
Bitsqueezer
Im Profil kannst Du frei den Rang ändern
 
Beiträge: 6477
Registriert: 21. Jun 2007, 12:17

Re: Access Backend nach MS SQL überführen, Fragen dazu.

Beitragvon GrandJop » 17. Jan 2018, 15:58

Hallo Christian

Vielen Dank für deine Antwort.

Welchen Weg empfiehlst du mir um Querys von Access in SQL-Server zu überführen und dann im FE anzeigen zu lassen?
Wenn möglich würde ich ohne ODBC arbeiten (sprich externe Verbindung), wenn aber eine direkte Verlinkung einer View usw. besser ist, mache ich das natürlich.

Gruss
GrandJop
GrandJop
Im Profil kannst Du frei den Rang ändern
 
Beiträge: 188
Registriert: 03. Aug 2016, 15:44

Re: Access Backend nach MS SQL überführen, Fragen dazu.

Beitragvon Bitsqueezer » 17. Jan 2018, 19:22

Hallo,

wenn Du meinst, Abfragen, die Du in Access erstellt hast, als View in SQL Server umzuformulieren, ist der einfachste Weg (nachdem natürlich alle Tabellen etc. übertragen wurden), in Access bei der Abfrage auf die SQL-Ansicht zu schalten und den Text in den SQL-Text der View zu kopieren. Dann muß man ggf. noch ein paar Feinheiten verbessern (etwa den Schemanamen zu einem Tabellennamen hinzufügen, in Access gibt es keine Schemas) und speichern.

Dann kannst Du die erstellte View wieder wie eine Tabelle in Access verlinken (das wäre der Standardweg, der am einfachsten umzusetzen ist und DAO verwendet).
Wenn Du das so machst, mußt Du allerdings bei jeder Änderung im Design der zugrundeliegenden Tabellen oder Views die Verlinkung im Frontend wieder löschen und neu einbinden (wie bereits oben erwähnt, macht man das per Code für alle Links in einem Rutsch).

Ich persönlich hatte zuviel ärgerliche Probleme mit DAO dazwischen und bin daher auf ADP umgeschwenkt, wo es nur ADO und keine ACE-Engine dazwischen gibt. Hier können die Views direkt als Recordsource ausgewählt werden.
Leider werden ADPs ab A2013 nicht mehr unterstützt, man muß dann maximal A2010 verwenden. Da ADPs an SQL Server gebunden sind, kann dann auch maximal SQL Server 2008R2 eingesetzt werden, neuere auf eigenes Risiko.

Beide Varianten haben aber ihre Schwächen und so setze ich mittlerweile auch die ADP nicht mehr in ihrem eigentlichen Sinn ein, sondern erstelle grundsätzlich für alle Formulare/Reporte ein ADO-Recordset, das auf einer View, Stored Procedure oder UDF basieren kann (während die anderen beiden Methoden auf Tabellen und Views beschränkt sind). Das passiert per VBA in Form_Open und dann wird das erstellte Recordset dem Formular-Recordset zugewiesen. Das funktioniert tadellos und einfach, man kann das alles schön in Standardklassen auslagern, die dann die "Schwerarbeit" für alle Formulare übernehmen können.
Vorteile dieser Methode sind, daß man auf beliebige Art ein ADO-Recordset erstellen kann, daß die Performance sehr gut ist und daß man die Methode gleichermaßen mit ADPs wie mit ACCDBs/MDBs verwenden kann. Nachteil ist natürlich vor allem ein hoher Programmieraufwand am Anfang, bis man all diese Standardverarbeitung, die Access sonst selbst übernimmt, selbst programmiert hat (jedoch bleiben viele Automatismen wie die Verarbeitung der Datensätze in Formularen (speichern, ändern, löschen) erhalten). Darüber hinaus muß man auch ein paar Automatismen von Access abschalten und selbst übernehmen, wie das Aktualisieren des Recordsets per F5-Taste - das funktioniert nur, wenn es nicht um Stored Procedures oder UDFs geht, die Parameter benötigen. Bei Views geht es und bei parameterlosen SPs und UDFs. Daher muß man die F5-Taste per AUTOKEYS-Makro abfangen und selbst die Aktualisierung per VBA neu anstoßen.

Die Kombi mit ADP und selbsterstellten Recordsets ist dabei immer noch die beste, da man so zwingend ausschließlich den SQL Server für die Datenbank verwenden muß und keine lokalen Tabellen verwenden kann, außerdem kann man den Loginuser der ADP mit so wenig Rechten ausstatten, daß die ADP in der Navigationsliste keine Ressourcen außer vielleicht einer Login-Prozedur anzeigt.

Wenn Du eine ACCDB verwenden willst und mit Links arbeiten möchtest, solltest Du ODBC grundsätzlich nicht verwenden, sondern stattdessen eine DSNlose Verbindung. Dabei wird der gesamte Connectionstring direkt im Link gespeichert und nicht erst auf eine externe ODBC-Einstellung zurückgegriffen. Ansonsten ändert sich nicht viel, außer daß eine DSNlose Verbindung nicht nach einem SQL Server Login fragt, im Gegensatz zu ODBC. Natürlich nur, wenn man SQL Server Logins und nicht Windows Authentication verwendet, was üblicherweise die bevorzugte Authentifizierung ist.

Gruß

Christian
Bitsqueezer
Im Profil kannst Du frei den Rang ändern
 
Beiträge: 6477
Registriert: 21. Jun 2007, 12:17

Re: Access Backend nach MS SQL überführen, Fragen dazu.

Beitragvon Nouba » 18. Jan 2018, 06:40

@Christian,

man kann einem auch das Wort im Mund herumdrehen. :) Aber vielleicht sollte ich es bzgl. Microsoft SQL-Sever besser mit Dieter Nuhr halten: Wenn man keine Ahnung hat, einfach mal Fresse halten.
mit freundlichen Grüssen Nouba

Wenn beim Lesen eines Beitrags der Eindruck entsteht, dass sich der Fragesteller wenig Mühe gegeben hat, so erhöht das nicht unbedingt die Motivation, eine Antwort zu verfassen.
Nouba
Im Profil kannst Du frei den Rang ändern
 
Beiträge: 16762
Registriert: 13. Mär 2006, 12:55
Wohnort: Berlin

Re: Access Backend nach MS SQL überführen, Fragen dazu.

Beitragvon Bitsqueezer » 18. Jan 2018, 07:40

Hallo Nouba,

man kann halt auch nicht jede Feinheit jedes Datenbankservers kennen. Ich würde die gleiche Aussage niemals über Oracle etc. treffen, weil ich nicht weiß, wie die sich dabei verhalten.

Bin mir aber nicht bewußt, Dir irgendwas rumgedreht zu haben, ich greife auch eher selten in die Futterluke eines Anderen... :lol:

Gruß

Christian
Bitsqueezer
Im Profil kannst Du frei den Rang ändern
 
Beiträge: 6477
Registriert: 21. Jun 2007, 12:17

Re: Access Backend nach MS SQL überführen, Fragen dazu.

Beitragvon Nouba » 18. Jan 2018, 08:26

@Christian,

ich habe bei der View impliziert, dass Daten aus mehreren Tabellen eingefügt, geändert, gelöscht werden sollen und kann mich dabei auch nur auf PostgreSQL (deswegen ja auch der Nuhr) berufen - vermute aber, dass der SQL-Server ähnliche Vorgehensweisen erfordert.

Stark vereinfachtes Beispiel mit zwei Tabellen:
Code: Alles auswählen
-- Table: public.product

-- DROP TABLE public.product;

CREATE TABLE public.product
(
  product_id integer NOT NULL DEFAULT nextval('product_product_id_seq'::regclass),
  product_name character varying,
  CONSTRAINT product_pkey PRIMARY KEY (product_id)
);

-- Table: public.purchase

-- DROP TABLE public.purchase;

CREATE TABLE public.purchase
(
  purchase_id integer NOT NULL DEFAULT nextval('purchase_purchase_id_seq'::regclass),
  product_id integer NOT NULL,
  when_bought date,
  CONSTRAINT purchase_pkey PRIMARY KEY (purchase_id),
  CONSTRAINT purchase_product_id_fkey FOREIGN KEY (product_id)
      REFERENCES public.product (product_id) MATCH SIMPLE
      ON UPDATE NO ACTION ON DELETE NO ACTION
);

-- View: public.purchaseview

-- DROP VIEW public.purchaseview;

CREATE OR REPLACE VIEW public.purchaseview AS
 SELECT purchase.purchase_id,
    product.product_name,
    purchase.when_bought
   FROM purchase
     LEFT JOIN product USING (product_id);

Ich will nun einige Produkte mit Kaufdatum über die View einfügen.
Code: Alles auswählen
INSERT INTO PurchaseView(product_name, when_bought)
  VALUES ('foo', Now()), ('bar', Now()), ('bar', '2018-01-16'::date) RETURNING *;

Dazu bedarf es in PostgreSQL eines INSTEAD OF Triggers auf die View.
Code: Alles auswählen
-- Trigger: insert_productview_trig on public.purchaseview

-- DROP TRIGGER insert_productview_trig ON public.purchaseview;

CREATE TRIGGER insert_productview_trig
  INSTEAD OF INSERT
  ON public.purchaseview
  FOR EACH ROW
  EXECUTE PROCEDURE public.insert_purchaseview_func();

Die Prozedur ist der Übersicht wegen ausgelagert.
Code: Alles auswählen
-- Function: public.insert_purchaseview_func()

-- DROP FUNCTION public.insert_purchaseview_func();

CREATE OR REPLACE FUNCTION public.insert_purchaseview_func()
  RETURNS trigger AS
$BODY$
DECLARE
tmp RECORD;
BEGIN
    IF NOT EXISTS (SELECT 1 FROM product
                   WHERE  product_name = NEW.product_name) THEN
      INSERT INTO product (product_name) VALUES (NEW.product_name);
    END IF;
   
    WITH input  (product_name, when_bought) as (
       VALUES (NEW.product_name, NEW.when_bought)
    )
    INSERT INTO purchase(product_id, when_bought)
    SELECT product_id, when_bought
    FROM input
    LEFT JOIN product USING (product_name)
    RETURNING purchase_id INTO tmp;
    NEW.purchase_id = tmp.purchase_id;
    RETURN NEW;
END;
$BODY$
  LANGUAGE plpgsql VOLATILE
  COST 100;
mit freundlichen Grüssen Nouba

Wenn beim Lesen eines Beitrags der Eindruck entsteht, dass sich der Fragesteller wenig Mühe gegeben hat, so erhöht das nicht unbedingt die Motivation, eine Antwort zu verfassen.
Nouba
Im Profil kannst Du frei den Rang ändern
 
Beiträge: 16762
Registriert: 13. Mär 2006, 12:55
Wohnort: Berlin

Re: Access Backend nach MS SQL überführen, Fragen dazu.

Beitragvon Bitsqueezer » 18. Jan 2018, 09:40

Hallo Nouba,

auf alle Fälle interessant zu sehen, wie unterschiedlich SQL-Dialekte sein können, da ist PostgreSQL wohl bisher am weitesten entfernt von den üblichen Standards. Bei Oracle sieht vieles noch sehr ähnlich aus, MySQL ist schon weiter weg, aber hier sieht es ja schon fast aus wie ein eigener SQL-Dialekt...:-)

Im Prinzip hast Du recht, natürlich muß man bei der Vorgehensweise aus Deinem Code, also gleichzeitiges Einfügen von Daten in mehr als einer Tabelle, bei SQL-Server genauso vorgehen, wie ich ja auch oben beschrieben habe. Was ich meinte ist, daß Deine Aussage "eine View mit mehr als einer Tabelle ist standardmäßig read-only" zumindest bei SQL Server (und auch Access selbst) nicht richtig ist. Ich weiß nicht, wie PostgreSQL sich verhält, wenn Du eine View entsprechend vorbereitest und Daten in der View in nur einer Tabelle gleichzeitig einfügst (also entweder Product_Name oder When_Bought in Deinem Beispiel in einem INSERT, ohne Trigger).

Aber interessant auch andere Syntax-Details, die ich aus SQL Server nicht kenne. Daß "NEW" vermutlich das Pendant zur SQL Server "inserted"-Tabelle ist, kann man sich ja noch erklären. Aber die "RETURNING"-Klausel in Zusammenhang mit "*" erschließt sich einem beim Lesen nicht. In Deiner SP hast Du eine Variante von "RETURNING" mit "INTO", das würde ich dann als Pendant zur "OUTPUT"-Klausel in SQL Server sehen.

Ein "FOR EACH ROW" gibt es in SQL Server leider auch nicht, würde vieles vereinfachen. Hier muß man stattdessen mühsam einen Cursor aufbauen und das Ergebnis in eine Variable je Feld schreiben.
Aber davon unabhängig würde ich in einem Trigger, sofern vermeidbar, auch ein "FOR EACH ROW...EXECUTE" nicht verwenden, da das bedeutet, daß für jede eingefügte Zeile eine SP einzeln aufgerufen wird, die nur eine Zeile bearbeitet. Das wäre wenig performant, wenn man ein "INSERT...SELECT" auf diese View mit größerer Datenmenge verwenden würde. Da würde ich stattdessen einen INSERT..SELECT mit einer OUTPUT-Klausel verwenden, der die eingefügten IDs dann in eine Temp-Tabelle schreibt und diese dann für das Einfügen des FK in der anderen Tabelle mit einem weiteren INSERT..SELECT verwendet - eben Set-based, nicht prozedural.
Der Vollständigkeit halber sollte ein Trigger auch immer eine Fehlerbehandlung und ggf. eine Transaktion verwenden, da besonders hier auch mehr als eine Tabelle betroffen ist.
Aber das nur am Rande.

Darüber hinaus verwendet Dein Beispiel einen LEFT JOIN, der nochmal anders zu bewerten wäre als ein INNER JOIN. Bei einem LEFT JOIN könnte die zweite Tabelle ggf. auch keinen korrespondierenden Datensatz ergeben, was beim Einfügen eines FK in die erste Tabelle erst einen INSERT in die PK-Tabelle erforderlich macht. Das funktioniert z.T. in Access selbst, weil Access hier Automatismen anbietet, die das selbst erledigen, bei SQL Server nicht. Da würden nur Daten in die zweite Tabelle geschrieben werden, wenn dort bereits ein Datensatz existiert.

Gruß

Christian
Bitsqueezer
Im Profil kannst Du frei den Rang ändern
 
Beiträge: 6477
Registriert: 21. Jun 2007, 12:17

Re: Access Backend nach MS SQL überführen, Fragen dazu.

Beitragvon Nouba » 18. Jan 2018, 11:19

@Christian,

so hat jedes Produkt seine Eigenheiten. PL/pgSQL ist nur eine von vielen prozeduralen Sprachen (vermutlich aber die geläufigste), die in PostgreSQL verwendet werden kann.

In PostgreSQL gibt es auch Updateable Views, die ohne Trigger auskommen. Diese einfachen Views sind automatisch aktualisierbar. Das System erlaubt die Verwendung von INSERT-, UPDATE- und DELETE-Anweisungen auf der View wie auf einer regulären Tabelle. Ein View ist automatisch aktualisierbar, wenn sie alle folgenden Bedingungen erfüllt:

* Die View muss genau einen Eintrag in ihrer FROM-Liste haben, der eine Tabelle oder eine andere aktualisierbare View sein muss.

* Die View-Definition darf auf der obersten Ebene keine WITH-, DISTINCT-, GROUP BY-, HAVING-, LIMIT- oder OFFSET-Klauseln enthalten.

* Die View-Definition darf auf der obersten Ebene keine Mengenoperationen (UNION, INTERSECT oder EXCEPT) enthalten.

* Die Auswahlliste der View darf keine Aggregate, Fensterfunktionen oder Set-Returning-Funktionen enthalten.

Eine automatisch aktualisierbare View kann eine Mischung aus aktualisierbaren und nicht aktualisierbaren Spalten enthalten. Eine Spalte ist änderbar, wenn es sich um eine einfache Referenz auf eine änderbare Spalte der zugrundeliegenden Basisrelation handelt; andernfalls ist die Spalte schreibgeschützt, und es wird ein Fehler ausgelöst, wenn eine INSERT- oder UPDATE-Anweisung versucht, ihr einen Wert zuzuweisen.

Wenn die View automatisch aktualisierbar ist, konvertiert das System jede INSERT-, UPDATE- oder DELETE-Anweisung des Views in die entsprechende Anweisung der zugrundeliegenden Basisrelation. INSERT-Anweisungen, die eine ON CONFLICT UPDATE-Klausel haben, werden voll unterstützt.

Wenn eine automatisch aktualisierbare View eine WHERE-Bedingung enthält, schränkt diese Bedingung ein, welche Zeilen der Basisrelation durch UPDATE- und DELETE-Anweisungen auf dem View modifiziert werden können. Ein UPDATE darf jedoch eine Zeile so ändern, dass sie die WHERE-Bedingung nicht mehr erfüllt und somit nicht mehr durch den View sichtbar ist. Ähnlich kann ein INSERT-Befehl potentiell Basisrelationszeilen einfügen, die nicht der WHERE-Bedingung genügen und daher nicht durch die View sichtbar sind (ON CONFLICT UPDATE kann sich ebenfalls auf eine bestehende Zeile auswirken, die nicht durch die View sichtbar ist). Die Option CHECK OPTION kann verwendet werden, um zu verhindern, dass INSERT- und UPDATE-Kommandos solche Zeilen erzeugen, die durch die View nicht sichtbar sind.

Neben Instead Of Trigger existiert noch ein etwas exotisches Regel-System (Rules), welches historisch gesehen weitaus früher als Instead Of Trigger implementiert wurde. Es ist jedoch schwierig zu durchschauen und wird von mir aus diesem Grund auch gemieden.

Wenn der INSERT-, UPDATE- oder DELETE-Befehl eine optionale RETURNING-Klausel enthält, ist das Ergebnis ähnlich wie bei einer SELECT-Anweisung, die die Spalten und Werte entsprechend der RETURNING-Liste ausgibt.
mit freundlichen Grüssen Nouba

Wenn beim Lesen eines Beitrags der Eindruck entsteht, dass sich der Fragesteller wenig Mühe gegeben hat, so erhöht das nicht unbedingt die Motivation, eine Antwort zu verfassen.
Nouba
Im Profil kannst Du frei den Rang ändern
 
Beiträge: 16762
Registriert: 13. Mär 2006, 12:55
Wohnort: Berlin

VorherigeNächste

Zurück zu Access Forum (provisorisch)

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 8 Gäste