Office: (Office 2003) Leerschritte in Firebird DB

Hallo zusammen

ich entwerfe hier gerade eine kleine Anwendung welche mit einer Firebird DB zusammen arbeitet - auf der anderen Seite ist ein DMS System welches ebenfalls mit dieser FB DB arbeitet - auf DB und DMS habe ich keinen Einfluss.

Mein problem sieht wie folgt aus:

Entweder FB oder das DMS füllt bei TEXTFELDERN am ende eines Strings alles mit "Leerzeichen" auf.

Beispiel: Es ist folgender String einer ET Nummer gespeichert:

"B6Y1-14-302 9A"

Dann ist in der DB gespeichert:

"B6Y1-14-302 9A "

Die hinten angehängte Leerzeichen kann ich natürlich innerhalb von VBA rauswerfen - ABER - wie mache ich hier für ein RecordSet einene funktionierende "Where SQL" Klausel ?

Mit "Where ETNR Like "B6Y1-14-302*" kann ich nicht arbeiten da es z.b: auch "B6Y1-14-302A oder B6Y1-14-302 9A" usw geben kann.

Mein Gedanke war jetzt in der Where Klausel die entsprechende "Leerschritte" aufzufüllen...

Was meint Ihr ?

:)

 

Welcher Datentyp wird innerhalb von Firebird verwendet?

Das macht VBA bei einem String fixer Länge.
Du könntest es damit versuchen.

Verwendest du PassThrough bzw. ADODB oder Verknüpfungen?

 

Hi

Ich habe die Tabellen ganz normal per odbc eingebunden und nutze ein normales RS

 

Hi

Ich habe die Tabellen ganz normal per odbc eingebunden und nutze ein normales RS

 

Code:

 

Nein, bloß nicht! Damit machst du jegliche Indexnutzung und serverseitige Abfrageoptimierung unmöglich.

 

Vermutlich ist der Datentyp auf dem Server CHAR(x). x definiert die Länge des Feldes. Beim CHAR Datentyp wird ein Feld immer auf seine definierte Länge mit Leerzeichen aufgefüllt.

In der Situation ist es wahrscheinlich tatsächlich am besten, die Suchkriterien analog zu behandeln und mit Leezeichen bis zur definierten Länge aufzufüllen.

 

Hi

klappt - ich habe ne kleine Routine gemacht die jeden String auf die fixe Breite hinten auffüllt - damit läuft das wie gewünscht ...

Manchmal muss man echt von hinten durch ....

 

[OT, da die Lösung mit dem Auffüllen meiner Meinung nach am besten/sichersten ist]

Hallo!

Kleiner Einspruch *wink.gif*
Das kommt darauf an, auf welcher Seite der Index wirken soll.
Wenn nur ein Index für ETNR genutzt werden soll, ist der obige Ausdruck keine Index-Behinderung.

mfg
Josef

 

Hallo

So da la ...

Performant ist das nicht...
Das sind aber auch gigantische Tabellen ...

Evtl ueberrede ich den db admin noch eine vier für mich anzulegen...

 

Kleiner Widerspruch zum Einspruch! ;-)

• Da sich die Leerzeichen im DB-Feld befinden, muss sich das Trim() auf ein DB-Feld beziehen, sonst tut es nix.
• Wenn kein Index vorhanden ist oder ein vorhandener nicht genutzt werden soll, ist es natürlich keine Index-Behinderung.
• Trim ist eine Access/VBA-Funktion. Ich habe nicht explizit geprüft, ob diese über ODBC an Firebird durchgereicht werden kann, aber die Wahrscheinlichkeit ist IMO nahe 100%, dass diese Funktion dazu führt, dass die komplette Verarbeitung der Where-Condition von Access und nicht vom Server durchgeführt wird.

 

Man sollte in Betracht ziehen, dass bei dem rechten Feld des Vergleichs ebenfalls ein Tabellenfeld statt eines Parameters vorliegen könnte. Dann könnte/müsste man abwägen, auf welches der Felder man die Berechnung performanceschonender vornehmen könnte.

Hat man auf der einen Seite einen Parameter, also einen dann konstanten Wert, dürften keine Fragen offen bleiben.

 

Wenn alle verwendeten Tabellen in der der gleichen DB sind, könnte eine Pass-Through-Abfrage die Auswertungsgeschwindigkeit erhöhen - so kann man zumindest ausschließen, dass Access/Jet/ACE in die Sql-Ausführung "reinpfuscht".

mfg
Josef