Hallo!

> vielen Dank f�r die Antworten.
> Mit Download und Installation von MDAC 2.7 war das Problem "80004005"
> behoben.
> (als ob es nie existiert h�tte)
> Da w�r ich allein ja nie drauf gekommen.
> Jetzt kann ich endlich wieder 'effektiv' arbeiten.

;-)
Stand schon mindestens 20 mal hier in der Liste.

> Die Fehlerdatei (500-100.asp) hab ich auch ge�ndert
> (und mir fest vorgenommen mich in der n�chsten Zeit mal n�her mit
> objASPError zu besch�ftigen).
>
> den Fehler, den rs.close verursacht hab ich auch gefunden. (Ich k�nnt
�ber
> mich selbst lachen)
> Ohne �ffnen kein schlie�en.
>
> noch kurz: Set rs = con.Execute(sql) kann auch bei Insert und Update
> Anweisungen sinnvoll sein,
> wenn man etwas �ber die Anzahl der ge�nderten Zeilen wissen m�chte.
> --> Set rs = con.Execute(sql, num) : Response.Write num & " Zeilen
> geändert"

Also wenn Du die Anzahl der modifizierten Datens�tze nach der Abfrage
haben willst, solltest Du einfach "con.Execute(sql, num)", also ohne
"Set rs = " aufrufen. Es wird n�mlich kein Objekt zur�ckgegeben, also
brauchst Du auch keine Zuweisung.

> trotzdem w�rde ich gerne wissen, was mit den von Joachim
angesprochenen
> vordefinierten,
> parametrisierten Abfragen gemeint ist. (wenn man danach im
Listenarchiv
> sucht, keine Ergebnisse)

Ich meine damit genau das gleiche, nur dass der SQL-String einmal in der
Datenbank und nicht laufend im VBScript-Code erstellt wird, also, dass
man die komplette Abfrage in Access oder im SQL-Server entwickelt,
testet und abspeichert. Das ist sehr viel performanter, als die
SQL-Befehle mit langsamen Zeichenkettenoperationen in VBScript
zusammenzusetzen.

Im SQL-Server kann man Views und auch komplexe Stored Procedures
definieren, in Access geht das mit allen m�glichen Abfragetypen und
einfachen Stored Procedures.

Ohne Parameter werden diese dann mit "con.Execute" bzw. "set rs =
con.execute" aufgerufen. Und das Command-Objekt unterst�tzt auch
Parameter, also "cmd.Execute(RecordsAffected, array(Param1, Param2,
...))" bzw. mit "set rs = cmd.Execute(...)"

Also: Trennung von Daten- und Businesslogik, keine
Datentypenkonvertierung, effizientere Fehlersuche und mehr Performanz.

> wonach kann ich da noch suchen?

"Abfragen definieren" in Access und "Command-Objekt" in ADO.
;-)

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

Antwort per Email an