Office: (Office 2016) funktionierenden INSERT

Servus,
folgende Prozedur funktioniert.
Meine Frage ist, ob das vereinfacht werden kann.
Der Code ist im Zuge einer Tabellenmodell-Optimierung
nur einmal notwendig. Mich stört dabei, dass NullWertfelder
den Wert 0 erhalten müssen, denn ansonsten gibt es eine Meldung über Syntaxfehler.
Danke im Voraus für jede Antwort.
Code:

:)

 

Ich bin nicht sicher, ob ich dein Problem richtig verstehe.
Könnte das Folgende die Lösung sein?

Code:

 

Servus Sonic8,
das löst das 0 Problem, danke.
Trotzdem lässt es bei mir ein Fragezeichen übrig.
Das Feld ebay ist Dateityp Zahl (double).
Warum muss man das mit einem String "NULL" bei der NZ-Funktion bedienen?

 

Hallo Ohrkester,

warum der Umweg über ein Recordset, ginge doch auch mit einer Anfügeabfrage mit "INSERT INTO ... SELECT ... "?
oder aber mit einer Parameter-Query in diesem Stil:
Code:

Die besondere Behandlung von NULL ist ja zum einen dem zusammengesetzten SQL String geschuldet und der Anwendung der Replace Funktion.
Bei einer Parameterquery würde man NULL direkt zuweisen und die Konvertierung mit Replace mit if not isNull() aufrufen.

Gruß Ulrich

 

Bei einer Parameterquery oder einfügen per Abfrage braucht man doch gar keine der hier verwendeten Funktionen.

Die Probleme kommen doch nur, wenn man per VBA beginnt Strings zu basteln.
Aber natürlich warum einfach, wenn es auch kompliziert geht.
Wo man doch immer und überall diese dilettantische Arbeitsweise zum Kopieren vorfindet. *grins

 

Servus knobbi38,
da brauch ich jetzt erst einmal einen Whiskey.....Lol
Das zu begreifen werd ich morgen versuchen.

 

Bei einer Parameterabfrage braucht man keine Konvertierung. Da geht Double so wie es ist an das Double-Feld, wie auch bei einer richtigen Anfügeabfrage (Tabelle an Tabelle) [2] wie auch, wenn man schon Recordsetschleifen liebt, bei Übergabe an ein schreibendes Recordset [3].
NULL-Inhalte sind in allen drei Varianten auch kein Problem, sprich bedürfen keiner Behandlung.

Eine richtige Anfügeabfrage [2] wäre hinsichtlich Einfachheit und Performance wohl kaum zu schlagen, aber ...

... das Naheliegende und Native in einer DB ist "undenkbar".

 

\@markusxy:

Richtig, normalerweise nicht. Ich bin jetzt aber mal davon ausgegangen, daß Ohrkester die Konvertierung von "," -> "." nicht grundlos eingebaut hat, die Quelldaten kenne ich ja nicht. Bei Double -> Double habe ich da auch meine Zweifel, vielleicht wenn die Tabellen mit verschiednen Language Settings erstellt worden sind.
Wie dem auch sei, wenn die Konvertierung tatsächlich benötigt wird, muß NULL abgefangen werden weil Replace damit nicht umgehen kann.
Insofern stimmt die Aussage von Eberhard nur bedingt, daß "bei einer Parameterabfrage keine Konvertierung gebraucht wird".

Und richtig, eine Anfügeabfrage mit "INSERT INTO ... SELECT ... " ist allemal das einfachste.

Gruß Ulrich

 

Zur Erinnerung: Die Quelldaten sind vom Typ Double und kommen aus einer (Datenbank?)Tabelle, sollten also typensicher sein.
Die Konvertierung ist keine Konvertierung, sondern nur eine Behandlung des Dezimaltrenners (die man übersichtlicher und einfacher per Str vornehmen würde), welche aber nur notwendig wird, wenn man von außen per Variablen Werte per SQL einbringt, wenn man SQL-Anweisungen zusammensetzt (Dynamik SQL).

Zielsicher wurde also ursprünglich eine Gestaltung gewählt, die praktisch maximal umständlich ist und genügend Raum für Fehler bietet.

Unberücksichtigt, wie tbl_EinAus bereits in ein Datenmodell eingebaut ist (was aber bei einer einmaligen Maßnahme auch kein Problem sein wird, da man nur die Art und Reihenfolge der Schritte etwas anders legen müsste), geht auch eine simple Tabellenerstellungsabfrage:
Code:

Anstatt Übertrag von SELECT * ... könnte man auch schlicht die Tabelle kopieren unter dem neuen Namen oder die Tabelle einfach umbenennen. Die nachfolgende Umbenennung des einen Feldes kriegt man dann auch hin, per Hand oder per Code.
Die Frage nach Vereinfachung kann man sich jetzt neu beantworten.

 

Ja, wenn dann natürlich.
Wie schon gesagt, wenn man nicht mit Strings herumbastelt,
dann braucht man das Ganze nicht.
Weil wenn das Replace nicht eingesetzt wird, dann muss man auch Null nicht entfernen.

Mit Strings sollte man es aber trotzdem lösen können.
Sonic8 hat eine schöne Lösung gezeigt.
Denn in manchen Fälle z.B. Suche im Recordset - geht die SQL Anweisung nur per String.
In diesem Fall ist dein Vorschlag mit Parametern aber sicher ein optimaler Ansatz, weil man dabei auf das String Gemurkse verzichten kann.

 

Der Charme des Vorschlages liegt aber darin, dass in der Zieltabelle NULL ankommt und eben nicht 0, wenn in der Quelltabelle NULL steht.
Mit einer Fehlervermeidung hat das weniger zu tun. Replace ist es egal, ob es statt des einzelnen Zeichens 0 eine Zeichenkette mit vier Zeichen als Ersatzwert für NULL vorgesetzt bekommt, um darin vergeblich nach einem Punkt zu suchen.

 

Hallo,
Die Steuerung dieses Kopierprozesses soll (wie ersichtlich) über eine VBA-Ereignisprozedur gehen.
Also wird das "Stringgestöpsel" bei SQL Strings wie auch immer bleiben müssen und wie mit dem zusätzlichen Hinweis von Sonic8 auch in dem gezeigten Code funktionieren.
Dass es auch ohne "Stringgestöpsel" gehen kann, erreicht man, indem man
mit Addnew, Update etc. in Recordsets per VBA Loops arbeitet, was übrigens eine sehr simple Anwendungsart sein kann bei einmaligen Prozessen.
Ich wollte diese Variante aber nicht anwenden, obwohl ich sie natürlich ausprobiert hatte.
Um es abzukürzen habe ich nun über VBA eine INSERT-Abfrage erstellt und
das Problem gelöst (Stringgestöpsel inkl.)
AND THE WINNER IS: knobbi38 mit seinem Kommentar:

Hier mein neuer Code
Code:

 

Angesichts so einer Aussage fragt man sich, ob du auch gelernt hast, wie man mit Parametern sauber arbeiten könnte.
Weil das Insert into wird ja hoffentlich nicht neu für dich sein.
Dann hätte der Thread dich ja auch tatsächlich weiter gebracht. *wink.gif*

 

Servus,

Viele Wege führen nach Rom und der von knobbi38 zuletzt empfohlene ist ein absolut sauberer und auch der einfachste Weg in diesem Fall.
Mit Parametern in Queries umzugehen ist mir geläufig. Wozu diese Umständlichkeit?

 

Siehe #4: Es war eher der erste empfohlene Weg (Reihenfolge) von knobbi38 (u.a.). Die Priorisierung fand irgendwie anders statt.

Nebenbei: Für eine einmalige Ausführung machen Anlegen (und Löschenmüssen) einer gespeicherten Abfrage keinen Sinn. Der theoretische Vorteil der Nutzung eines gespeicherten Ablaufplanes tritt erst nach der ersten Ausführung ein. Daneben wird man für ein "SELECT *" keinen besonderen optimierten Ausführungsplan benötigen.
Die Ausführung der puren Anfügeabfrage tut es auch - für den Fall des Wunsches nach Vereinfachung und Verzicht auf On Error Resume Next .

Eine gute Frage, durch das ganze Thema hindurch.

Sowie:

Tabelle kopieren oder umbenennen o.a. kann man ebenfalls per VBA als praktischen Einzeiler umsetzen.