Hallo!
> > So habe ich es auch, allerdings ohne rs.Update (weil �berfl�ssig
nach
> > rs.AddNew mit Parametern). Auch bearbeite ich in der Funktion die
>
> Richtig, das ist �berfl�ssig... Ist irgendwie da reingerutscht...
> Wie gef�llt Dir den mein Auswahl-Kriterium(0=1), als Alternative zu
> ID=0, wozu man den ID-Namen wissen muss... Klever, nicht? ;-)
Das ist okay, zumal Du bei der R�ckgabe der ID ja auch darauf verl�sst,
dass der Primaray Key an erster Stelle steht.
Also okay: Das ist geil und ich werde es �bernehmen! Bisher hatte ich "
... where ... < 0"
> > "Access-Trigger", so dass meine Applikation sowohl mit Access als
auch
> > SQL-Server arbeiten k�nnen.
>
> Access-Trigger? Rufst Du Funktionen auf, die Trigger-Funktionalit�t
> nachbilden? Man muss dann aber trotzdem alles zweimal schreiben -
oder?
> Einmal die Trigger f�r SQLServer in T-SQL und einmal die
> Access-Pseudo-Trigger als Script!?
Ich habe ein paar Properties um zwischen Access und SQL Server hin und
herschalten zu k�nnen. Wenn die Funktion f�r SQL Server aufgerufen wird,
ist der Job getan, da die Trigger ja im SQL Server definiert sind. F�r
Access wird dann eine Tabelle "trigger" aufgerufen, in der
JET-SQL-Befehl mit der ID des modifizierten Datensatzes als Stored
Procedure definiert ist.
Set rt = dataExecute("GetTrigger", array(table, "insert"))
Do while not rt.Eof
Call dataExecute(rt.Fields("sql").value, array(id))
Loop
"dataExecute" ist mein Pendant zu Deinem "ExecuteRS" (mein "InsertRS"
hei�t ja auch "dataInsert")
Im SQL Server habe ich einen echten Trigger und in Access daf�r dann
eine oder mehrere Stored Procedures. Allerdings funktionieren noch keine
Instead-Of-Trigger (kommt demn�chst) und nat�rlich auch keine Updates
auf mehrere Datens�tze. Aber die macht man ja auch nicht mit
"dataInsert" bzw. "InsertRS" ...
> > Vielleicht ist es auch sinnvoll, die ID nicht mit rs(0), sondern mit
> > rs.Fields("ID").value zu suchen, weil die Reihenfolge ja auch
> > mal anders
> > sein kann. In Deinem Fall musst Du bei jeder Tabelle immer
> > zuerst die ID
> > definieren. In Access wirkt das Verschieben von Feldern nur auf die
> > Anzeige und nicht auf die gespeicherte Reihenfolge.
>
> So wie ich es im Moment mache ist es f�r mich sicherer, weil bei mir
> eigentlich das PK nie ID heisst, aber immer an erster Stelle in der
> Tabelle steht...
> Wenn man es allgemeing�ltig machen will, sollte man wohl noch einen
> Parameter in die Funktion �bergeben, der den Namen der
zur�ckzugebenden
> ID enth�lt...
Das ist "meine" Variante.
Freundliche Gr��e
Joachim van de Bruck
| [aspdedatabase] als [email protected] subscribed
| http://www.aspgerman.com/archiv/aspdedatabase/ = Listenarchiv
| Sie k�nnen sich unter folgender URL an- und abmelden:
| http://www.aspgerman.com/aspgerman/listen/anmelden/aspdedatabase.asp
