Firebirdforum.de

Nun ja, in unserer BI-Lösung wird sehr viel zur Laufzeit mit dynamischem DDL gearbeitet. Dies geht nun mal ausschließlich auf diesem Weg. Zusätzlich benötige ich da noch eine Sperrlösung, weil 2 DDL's gleichzeitg häufig zum DB-Crash führen. Aber das erledige ich mit einem "Select * from MyTable for ...

Auf 255 inserts komme ich ja noch nicht mal. a) komme ich da über 64 KB b) arbeite ich mit Parameter-Markern und da ist eine Pufferlänge beschränkt. Leider finde ich dazu keine Berechungsmethode. Außerdem wird eine global temorary table gar nicht in die DB geschrieben sondern in den Temp-Ordner, und...

Bestimmet DDL's kann man nur per dynamischem SQL erledig.
https://firebirdsql.org/refdocs/langref ... cstat.html
Das schöne ist, DDL per Execute unerliegt meist keiner Einschränkung.
Allerdings muss für die Änderung von Table-Metadaten die Tabelle exclusiv im Zugriff sein.

Nachtrag und neueste Erkenntnisse: Die Performancc hängt schon wesentlich von der Anzahl Spalten und somit auch von der Anzahl Parameter ab. Dabei bin ich allerdings auf ein Limit gekommen: Eine Prozedur/Block darf bis 64KB sein. Die Summe der Parameterfelder darf die aktuelle Zeilenlänge (64K) aber...

So, nun habe ich nach den obigen Prinzipien einen Execute Block generiet (62 KB) und es hat im Prinzip keinen Vorteil gebracht. Durch die lange Syntax (Parameter Definition, Insert-Befehle) habe ich mit z.B. 72 Spalten nur 16 Inserts zusammen gebastelt. Grundsätzlich funktioniert es, allerdings komm...

Allerdings muss man auch die andere Seite sehen, denn das Ausgeben von Daten erst in CSV dauert auch ebenso lange. Zusätzlich muss man dann noch berücksichtigen, dass - NULL's nicht übermittelbar sind - Codierungsschwierigkeiten auftreten (Datumsformat, Decimalpoint, u.ä.) - Text/Binär-Blobs auf die...

Da du ja Moderator bist, könntest du die Beiträge außer dem Ersten einfach in einen neuen Thread verschieben?
Ich möchte dann auf deine letzte Antwort noch etwas dazu sagen.

Nun, mit den von mir entwickelten und mit .Net unterstützten Verfahren konnte ich eine DB-Kopie, die ich mal für Notfälle erstellt hatte, um den Faktor 2,5 beschleunigen. Die Kopie ist dann eforderlich, wenn gback auch nach gfix einfach scheitert. Die reinen Datentabellen lassen sich dann immer noch...

Ja, einen Bulkload vesuche ich derzeit schon. Da ist der SQL-Server leider viel weiter, da in .Net eine eigene Klasse SqlBulkCopy angeboten wird. Meine Tests laufen im Moment ganz gut. Je nach Spaltenanzahl und Feldlängen varieirt dies derzeit zwischen 2.500 bis 8000 Inserts/Sekunde. Der SQL-Selver ...

Danke für die Antwort. Aber das ist ja absolut ein praxisferner Test. Wenn mit gesagt wird, dass eine DB um 10% schneller ist als vorher, ich aber meine Daten nicht um 10% schneller in die DB bekomme, ist das Augenwischerei. Klar ist auch, dass ein "for I = 1 to 1000000:next" unheimlich schnell ist,...