spinnt fb oder spinn ich?

[sancho1980]

hi leute

ich versuche grad eine sp gebacken zu bekommen und werd langsam verrückt.
grund: die sp läuft im ibexpert-debugger tadellos, aber wenn sie von firebird selbst ausgeführt wird, ist die ergebnismenge nicht korrekt.
habe eine test-datenbank, in der befinden sich unter anderem die felder asterm und id

die erwähnte prozedur soll folgendes tun:

dem benutzer sollen die nächsten 20 eintrag-ids aus tabelle dicentries zurückgeliefert werden; sortiert nach "asterm ascending, id ascending"
die parameter asterm_in und id_in bestimmen hierbei den einsprungspunkt in die tabelle, AB DEM die 20 einträge zurückgegeben werden sollen
die prozedur sieht folgendermaßen aus:

SQL-Code:

CREATE PROCEDURE NEXT_20_AB_ASTERM (
    asterm_in varchar(240),
    id_in bigint)
returns (
    id_out bigint,
    pos integer)
as
declare variable id_prior bigint;
declare variable asterm_temp varchar(240) character set unicode_fss;
declare variable asterm_prior varchar(240) character set unicode_fss;
begin
  pos = 0;
  ASTERM_prior = ASTERM_in;
  id_prior = id_in;
  for select ASTERM from dicentries where ((ASTERM = :ASTERM_prior and id >= :id_prior) or (ASTERM > :ASTERM_prior)) order by ASTERM ascending into :ASTERM_temp do
    begin
      if (ASTERM_temp > ASTERM_prior) then
        id_prior = 0;
      for select id from dicentries where ASTERM = :ASTERM_temp and id >= :id_prior order by id ascending into :id_out do
        begin
          suspend;
          pos = pos + 1;
          if (pos = 20) then
            exit;
        end
      id_prior = id_out + 1;
      asterm_prior = asterm_temp;
    end
end

ich gebe ein beispiel, wo diese prozedur das falsche ergebnis liefert (dazu die Test-Datenbank runterladen):

select * from next_20_ab_asterm('Lackreiniger, m', 34)

das korrekte ergebnis (so wie es auch im ibexpert-debugger ausgegeben wird) ist:

id_out

34
167
117
59
91
123
143
141
185
219
206
207
1
223
213
177
175
130
90
110


firebird 1.5 selbst aber gibt mir folgendes (falsches) ergebnis:

id_out

34
167
117
59
143
141
185
219
206
207
177
130
90
110
222
82
79
211
212
210


Ich weiß, dass ich diese sp auch einfacher haben könnte, nämlich in der art:

SQL-Code:

for select first 20 id from dicentries where (asterm = :asterm_in and id >= :id_in) or (asterm > :asterm_in) order by asterm ascending, id ascending into :id_out do suspend;

aber das wäre bei großen datenmengen zu langsam... (aber daran seht ihr wenigstens nochmal genau, was die sp genau machen soll)

weiß hier irgendeiner weiter?

danke,

martin

[sancho1980]

jetzt fällt mir ein, warum ihr vielleicht nicht antwortet: ihr braucht ja noch die collation: einfach fbintl2.dll in euer firebird-intl verzeichnis kopieren und server neu starten, dann geht die test-datenbank!

[mkinzler]

-Warum hängst du die datenbank nicht an den Artikel an?
-Warum verwendest du nicht das Limit/Row-Feature von FireBird?

[sancho1980]

row gibtst bei fb 1.5 nicht

erweiterung fdb ist als anhang verboten

[mkinzler]

Zitat:

Zitat von sancho1980

row gibtst bei fb 1.5 nicht

Die alte Syntax sollte aber auch bei FB1.5 gehen, sonst -> Update auf 2 (RC5 ist ja das letzte vor der Final)

Zitat:

erweiterung fdb ist als anhang verboten

Dann Zippe sie doch.

[sancho1980]

besser?

[hoika]

Hallo,

ich verstehe die SP einfach nicht. :wall:
Erklär doch mal genau, was du willst.
Dann checke mal die einzelnen SQL-Abfragen einzeln.
(per suspend in Hilfs-Return-Parametern)


Bau dir doch eine oder mehrere Hilfsvariablen als Return-Varsd ein,
zum "debuggen".
Das der Debugger was anderes anzeigt, kann vorkommen,
die FB ja keinen Debugger-Unterstützung hat.
Das was ibexpert macht, ist clientseitiges debuggen (oder udf glaueb ich).

Was anderes fällt mir noch zum Thema connection stirng ein,
hast du im ibexpert den charset bei den Registrierungs-optionen direkt mit angegeben ?
Dann musst du das auch in deiner App machen.

läuft denn die sp korrekt in ibexpert ohne debugger ?


Heiko

PS:
In meiner DB sind auch ein paar sp's.

[sancho1980]

hi

die sp erklären is ganz einfach; was sie machen soll ist:

SQL-Code:

pos = 0;
for select first 20 id from dicentries where (asterm = :asterm_in and id >= :id_in) or (asterm > :asterm_in) order by asterm ascending, id ascending into :id_out do
  begin
    suspend;
    pos = pos + 1;
  end

das problem ist, dass meine felder zuu groß sind - deswegen kann ich auf asterm, id keinen joint index kreiren.
das wiederum bedeutet, dass die prozedur so wie sie hier steht zu lange dauern würde; deswegen brauch ich eine andere sp, die mir genau das selbe ergebnis liefert - aber dabei schneller ist!

habe mittlerweile eine lösung gefunden, die funktioniert..bin immer noch der meinung, das was ich hier gepostet hab ist korrekt und firebird hat einen bug...sei's drum, so funktioniert's jetzt (indem ich das problem in zwei prizeduren aufteile):

SQL-Code:

CREATE PROCEDURE NEXT_20_AB_ASTERM_AUX (
    asterm_in varchar(240),
    id_in bigint)
returns (
    id_out bigint,
    pos integer)
as
declare variable cnt integer;
declare variable asterm_tmp varchar(240) character set unicode_fss;
declare variable asterm_prior varchar(240) character set unicode_fss;
begin
  pos = 0;
  cnt = 0;
  asterm_prior = asterm_in;
  for select asterm, id from dicentries where (asterm = :asterm_in and id >= :id_in) or (asterm > :asterm_in) order by asterm ascending into :asterm_tmp, :id_out do
    begin
      cnt = cnt + 1;
      if (asterm_tmp <> asterm_prior) then
        begin
          pos = pos + 1;
          asterm_prior = asterm_tmp;
        end
      suspend;
      if (cnt = 20) then
        exit;
    end
end

SQL-Code:

CREATE PROCEDURE NEXT_20_AB_ASTERM (
    asterm_in varchar(240),
    id_in bigint)
returns (
    id_out bigint,
    pos integer)
as
begin
  pos = 0;
  for select id_out from next_20_ab_asterm_aux(:asterm_in, :id_in) order by pos ascending, id_out ascending into :id_out do
    begin
      suspend;
      pos = pos + 1;
    end
end

[Hansa]

Der Titel ist schon mal echt gut. :stupid: Zeige mal, wie das ganze im Programm aussieht. Sind die Parameter tatsächlich richtig bestückt im Programm ? IBExpert macht nichts anderes, als Dein Programm auch (machen soll), Debugger hin oder her. Der Hund dürfte bei Dir begraben sein. Ich sehe dann noch Unicode in Verbindung mit IBX ? Geht das überhaupt ? Savepoints bei FB1.5 gehen mit IBX jedenfalls nicht. Und Unicode soll gehen ? :shock: Da würde ich mich mal genau vergewissern. Ok, Glaskugel gibt nicht viel mehr her. Könnte mir allerdings vorstellen, daß es Schwierigkeiten mit IBX/Unicode gibt und das gar nicht auffällt, weil eventuell dubiose Datensätze wegen der Begrenzung der Datenmenge am Schluß angezeigt werden, also quasi unsichtbar.

[sancho1980]

wieso? es funktioniert doch jetzt
außerdem ist der ibexpert debugger ein separates programm der sich u.U. anders verhalten kann als es fb letzten endes tut :mrgreen:

[Hansa]

Jo, ist wohl nix zu machen. Dann lebe eben damit, daß sich ein Programm mit demselben Datenbestand etwas anders verhält als Deines, ohne zu wissen weshalb. :mrgreen:

[sancho1980]

mein programm?
welches anderes programm?
ich red von ner sp.. :spin2:

[Hansa]

Bin von folgendem ausgegangen :

Zitat:

Zitat von sancho1980

grund: die sp läuft im ibexpert-debugger tadellos, aber wenn sie von firebird selbst ausgeführt wird, ist die ergebnismenge nicht korrekt.

Wenn es in IBExpert tadellos läuft und "in FB selbst nicht", was soll man dazu sagen ? Bin davon ausgegangen, daß "in FB" bedeutet : "außerhalb von IBExpert". Dein Programm benutzt ja hoffentlich dieselbe FB-Version wie IBExpert oder der -Debugger. Ist der extern, dann wären es schon 3 Programme. Hast Du eventuell sogar FB-GDS32 usw. -DLL Hickhack ? :shock: So, es läuft also mit IBExpert. Dann kann die SP ja gar nicht so falsch sein. Wieso gehts dann aber trotzdem nicht richtig ? Geht es vielleicht nur zufällig und nur momentan ? Ich könnte das Programm nicht ruhigen Gewissens so rausgeben, sondern würde der Sache auf den Grund gehen. Stelle Dir mal vor, es gibt tatsächlich einen Konflikt zwischen IBX und FB. Was dann ?

[mkinzler]

Zitat:

das problem ist, dass meine felder zuu groß sind - deswegen kann ich auf asterm, id keinen joint index kreiren.

???
Wie rufst du die SP außerhalb von IBExpert auf (in einem Delphiprogramm, einem anderen Admintool z.B. IB(O)Console oder ISQL?)
Schon mal mit FB2 versucht?

[sancho1980]

Zitat:

Zitat von Hansa

Bin von folgendem ausgegangen :

Zitat:

Zitat von sancho1980

grund: die sp läuft im ibexpert-debugger tadellos, aber wenn sie von firebird selbst ausgeführt wird, ist die ergebnismenge nicht korrekt.

Wenn es in IBExpert tadellos läuft und "in FB selbst nicht", was soll man dazu sagen ? Bin davon ausgegangen, daß "in FB" bedeutet : "außerhalb von IBExpert". Dein Programm benutzt ja hoffentlich dieselbe FB-Version wie IBExpert oder der -Debugger.

Eben nicht. Der Debugger benutzt nicht den Server, sondern ist ein eigenständiges Programm. Fb (zumindest 1.5) hat gar keine Debugger-Unterstützung.
Ich meinte nicht "außerhalb von IBExpert", sondern außerhalb vom Debugger..also die SP wurde im Debugger selbst (der ja eben NICHT auf die Engine zurückgreift) korrekt ausgeführt; bei Ausführung vom Server selbst aber nicht (also bsp-weise in isql, sql editor, der beispiele gibt es viele :-)

[sancho1980]

Zitat:

Zitat von mkinzler

Zitat:

das problem ist, dass meine felder zuu groß sind - deswegen kann ich auf asterm, id keinen joint index kreiren.

???
Wie rufst du die SP außerhalb von IBExpert auf (in einem Delphiprogramm, einem anderen Admintool z.B. IB(O)Console oder ISQL?)
Schon mal mit FB2 versucht?

fb 2 ist keine option weil ich mich daran schon mal versucht hatte; da hab ich erstmal gleich nen bug gefunden was das event-handling angeht(wie mir in fb-devel bestätigt wurde)..also bin ich mit fb2 vorsichtig...

[mkinzler]

Zitat:

fb 2 ist keine option weil ich mich daran schon mal versucht hatte; da hab ich erstmal gleich nen bug gefunden was das event-handling angeht(wie mir in fb-devel bestätigt wurde)..also bin ich mit fb2 vorsichtig...

Welche Version von FB hast du getestet? Die final steht ja vor der Tür, darin wird der Bug hoffentlich behoben sein.

[Hansa]

Sancho soll sagen, ob es sich lohnt weiter zu überlegen oder ob er mit Quereffekten leben kann. IMHO ist ein manchmal nicht/funktionierendes Programm viel schlimmer als eines, was von Anfang an nicht geht. :mrgreen: Man stelle sich mal vor, es wird mit dem "Effekt" gelebt und ein User kann damit umgehen. Dann kommt in 2 Jahren ein anderer und der hackt dann auf dem Fehler rum und motzt sonst auch nur rum. :wall:

@Sancho :

Zitat:

Zitat von sancho1980

...da hab ich erstmal gleich nen bug gefunden was das event-handling angeht...

Mit so was wäre ich äußerst vorsichtig. Erstens, ob es überhaupt ein Bug ist und zweitens mit Antworten von irgendwo von irgendwem. Viele "Bugs" lösen sich wegen selbst verschuldeter Fehler schnell in Luft auf. Was FB 2 betrifft : habe lange gezögert, es einzusetzen. Ich glaube, bei RC 3 oder sogar 4 habe ich es erst installiert. Und zwar erst dann wegen eines Irrtums. Es ging um den Umstieg auf C++. Habe gedacht, der käme erst in FB 2, aber das war schon mit FB 1.53. Mittlerweile sehe ich alleine schon deshalb FB 2 als sicherer an, als FB 1.5.

[sancho1980]

Zitat:

Zitat von Hansa

Sancho soll sagen, ob es sich lohnt weiter zu überlegen oder ob er mit Quereffekten leben kann. IMHO ist ein manchmal nicht/funktionierendes Programm viel schlimmer als eines, was von Anfang an nicht geht. :mrgreen: Man stelle sich mal vor, es wird mit dem "Effekt" gelebt und ein User kann damit umgehen. Dann kommt in 2 Jahren ein anderer und der hackt dann auf dem Fehler rum und motzt sonst auch nur rum. :wall:

@Sancho :

Zitat:

Zitat von sancho1980

...da hab ich erstmal gleich nen bug gefunden was das event-handling angeht...

Mit so was wäre ich äußerst vorsichtig. Erstens, ob es überhaupt ein Bug ist und zweitens mit Antworten von irgendwo von irgendwem. Viele "Bugs" lösen sich wegen selbst verschuldeter Fehler schnell in Luft auf. Was FB 2 betrifft : habe lange gezögert, es einzusetzen. Ich glaube, bei RC 3 oder sogar 4 habe ich es erst installiert. Und zwar erst dann wegen eines Irrtums. Es ging um den Umstieg auf C++. Habe gedacht, der käme erst in FB 2, aber das war schon mit FB 1.53. Mittlerweile sehe ich alleine schon deshalb FB 2 als sicherer an, als FB 1.5.

Wie gesagt, die SP funktioniert jetz

Wegen dem Bug: die ham dazu n richtig offizielles Protokoll geschrieben mit pipapo; glaub mir mal, es war ein bug...

[mkinzler]

Zitat:

Es ging um den Umstieg auf C++. Habe gedacht, der käme erst in FB 2, aber das war schon mit FB 1.53. Mittlerweile sehe ich alleine schon deshalb FB 2 als sicherer an, als FB 1.5.

Was hat den die verwendete Programmiersprache damit zu tun?

[Hansa]

Für Sancho scheint es ja so ausreichend zu sein. Insofern ist das Problem an sich ja erledigt.

Hier steht allerdings noch eine Rückfrage im Raum :

Zitat:

Zitat von mkinzler

Was hat den die verwendete Programmiersprache damit zu tun?

Was soll man da sagen ? Liegt das nicht auf der Hand ? Ist eher jetzt OT, aber für Neulinge ist das Thema vielleicht schon interessant im Zusammenhang. Man nehme ein Programm namens Interbase (ein DBMS), an dem der Hersteller Borland sein kommerzielles Interesse verloren hat und es freundlicherweise als Open Source zur Verfügung stellt. Es ist in C geschrieben. Einige Insider wissen vom Potential und setzen sich zusammen. Der Source ist ja jetzt vorhanden und es gilt einige tatsachlich länger vorhandene Bugs zu beseitigen plus kleinere Änderungen.

Ok, man hat ein besseres Interbase und nennt es Firebird 1.0. Was jetzt, wie gehts weiter ? Weil in C geschrieben, ist es in keinster Weise objektorientiert. Irgendwann muß es das aber werden. Ohne OOP oder mit, das sind aber jetzt grundsätzlich verschiedene Techniken. Auch wenn die C/C++ Syntax gleichermaßen kryptisch ist : die dahinterstehende Programmierlogik ist grundverschieden.

Und wenn ich mir jetzt noch den Zeitrahmen angucke, der zwischen IB 6.0 und FB 1.5 war : das war schon sehr knapp. Hut ab vor denen, die alles so hingekriegt haben (mit fremdem vorher nicht veröffentlichtem Source !). Im Nachhinein glaube ich, daß in der Roadmap der Umstieg auf C++ für FB 2.0 geplant war und anfangs nicht für 1.5 oder ich habe mich verlesen. Hätte ichs richtig gesehen dann wäre FB 1.5 vorerst ausgelassen worden. OOP betrifft im Falle von FB nur das Datenbank-Programm und nicht etwa das zugrunde liegende DB-Konzept. Siehe PostgreSQL. Die gingen noch einen Schritt weiter und haben OOP auch in der DB verwendet (so was in der Richtung : inherited "Feldtyp"). Sieht fast so aus, daß das zuviel des guten auf einmal war.

[mkinzler]

Das mit der Umstelleung con c nach c++ ist mir ja bekannt, nur finde ich es falsch daraus direkt auf sicher oder unsicher abzuleiten.