Results 1 to 12 of 12

Thread: Firebird 2.5 - Where clause "="

  1. #1

    Firebird 2.5 - Where clause "="

    Hallo hallo,

    Het lijkt erop alsof de string waarde in de where clause eerst getrimt wordt, voordat deze vergeleken wordt. De volgende queries geven allen hetzelfde record terug.

    Code:
    SELECT * 
    FROM "Countries"
    WHERE "CountryCodeI3A" = 'NOR'
    Code:
    SELECT * 
    FROM "Countries"
    WHERE "CountryCodeI3A" = 'NOR ' --Met spatie aan het einde
    Code:
    SELECT * 
    FROM "Countries"
    WHERE "CountryCodeI3A" = 'NOR ' --Met twee spaties aan het einde
    Heeft iemand een verklaring voor dit gedrag?

    De tabel definitie is als volgt:

    Code:
    CREATE TABLE "Countries" 
    (
      "CountryID"                      INTEGER         NOT NULL,
      "CountryName"                    VARCHAR(   100) NOT NULL COLLATE NONE,
      "CountryCodeI3A"                 VARCHAR(     3) NOT NULL COLLATE NONE,
      "RegionCode"                     VARCHAR(    20)  COLLATE NONE,
      "LangIDWeb"                      VARCHAR(    20)  COLLATE NONE,
      "CountryCodeExternal"         VARCHAR(     3)  COLLATE NONE,
      EU                              SMALLINT,
     CONSTRAINT "PK_Countries" PRIMARY KEY ("CountryID")
    );
    Bij voorbaat dank!

  2. #2
    Een CHAR is altijd padded met spaties.
    Zie http://www.firebirdfaq.org/faq237/
    Een VARCHAR echter niet.
    Ik denk dat firebird de 'NOR' ziet als CHAR en die is hetzelfde als 'NOR '.
    Er wordt dan altijd vergeleken alleen op 'NOR'.

    Probeer de VARCHAR in het records eens te zetten op 'NOR '.
    Wordt ie dan ook weergegeven bij where 'NOR' ?

    Je zou WHERE "CountryCodeI3A" = cast( 'NOR ' as VARCHAR(200)) kunnen proberen.

  3. #3
    Zowel de cast als het aanpassen van het record met een extra spatie geven hetzelfde resultaat als voorheen.

    Ik heb het voor de zekerheid getest met drie verschillende "tools" om uit te sluiten dat een "handige" tool een soort auto trim functie aan heeft staan.

    Ik denk dat firebird de 'NOR' ziet als CHAR en die is hetzelfde als 'NOR '
    Dat zou wel het gedrag verklaren, alhoewel ik het wel vreemd zou vinden als dit inderdaad het geval was.

    Kan me bijna niet voorstellen dat dit de manier is waarop Firebird werkt, dus waarschijnlijk doe ik iets doms

  4. #4
    Ja, je kunt het ook nog gekker hebben.
    Zie http://www.firebirdfaq.org/faq309/

    Alleen jij werkt met VARCHAR en als je dan een cast zou doen voor de constante, dan zou je zeggen dat je geen records met 'NOR ' terug zou mogen krijgen.

    Of alles wordt overal gewoon getrimd.

    Zie bv ook hier https://sourceforge.net/p/firebird/m...sage/17601667/

    Schijnbaar is het wel standaard (en niet firebird specific).
    https://sourceforge.net/p/firebird/m...sage/17601688/

    And in all versions of the SQL standard since the first. When comparing
    strings of different lengths for equality, the shorter string is padded
    with blanks to the length of the longer string. We may not agree with
    it, but it is the law.
    Er wordt dus niet getrimd maar er worden spaties toegevoegd tot de langste lengte.
    Last edited by rvk; 15-Oct-20 at 00:20.

  5. #5
    Dat verklaart een hoop. Blijf het wel een bijzondere ontwerp keuze vinden.

    Schijnbaar is het wel standaard
    Welke standaard is dit? SQL-92?

    Dank je wel Rik!

  6. #6
    Quote Originally Posted by luigi View Post
    Welke standaard is dit? SQL-92?
    Ja, onder andere ANSI/ISO SQL- 92.
    (Hij zegt ook alle standaarden sinds het begin)

    Zie bv https://support.microsoft.com/en-us/...railing-spaces

    Als je zoekt op SQL-92 padding spaces op google dan kom je het heel veel tegen.
    Dus het is inderdaad standaard.

    SQL Server follows the ANSI/ISO SQL-92 specification (Section 8.2, , General rules #3) on how to compare strings with spaces. The ANSI standard requires padding for the character strings used in comparisons so that their lengths match before comparing them. The padding directly affects the semantics of WHERE and HAVING clause predicates and other Transact-SQL string comparisons. For example, Transact-SQL considers the strings 'abc' and 'abc ' to be equivalent for most comparison operations.

    The only exception to this rule is the LIKE predicate. When the right side of a LIKE predicate expression features a value with a trailing space, SQL Server does not pad the two values to the same length before the comparison occurs. Because the purpose of the LIKE predicate, by definition, is to facilitate pattern searches rather than simple string equality tests, this does not violate the section of the ANSI SQL-92 specification mentioned earlier.

  7. #7
    Reader
    Join Date
    May 2002
    Location
    Holland
    Posts
    3,382
    Wow, ik heb net even gekeken met mijn boekhoudprogje (firebird 3.0 embedded) en tot mijn schrik maakt het in de where inderdaad niet uit of je er spaties achter plakt. Insane! Spaties zijn gewoon karakters in mijn beleving.

  8. #8
    Wow, ik heb net even gekeken met mijn boekhoudprogje (firebird 3.0 embedded) en tot mijn schrik maakt het in de where inderdaad niet uit of je er spaties achter plakt. Insane!
    Ben blij dat ik niet enige ben... en dat PostgreSQL zich van deze standaard zich niets aantrekt

  9. #9
    Ik draai al bijna 20 jaar met Firebird en heb hiermee nog nooit problemen meegemaakt.

  10. #10
    en dat PostgreSQL zich van deze standaard zich niets aantrekt
    Je kunt je afvragen of dat logisch is natuurlijk

  11. #11
    Reader
    Join Date
    May 2002
    Location
    Holland
    Posts
    3,382
    Code:
    'Eric' <> 'Eric   '
    We leven toch niet meer in de DBase tijd zeg...

  12. #12
    Je kunt je afvragen of dat logisch is natuurlijk
    Niet logisch, maar wel goed

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •