---

Jeg har en tabel som giver mig et problem:

Når jeg henter alt inholdet i tabelen (SELECT * FROM ...) virker det som
forventet, men når jeg kun vil hente en enkelt record (SELECT * FROM ...
WHERE x = '1') kommer der intet retur. Det er ligegyldigt hvilken felter i
tabellen jeg søger på, resultatet er det samme.

Nogen bud på hvad problemet skyldes?

Poul Erik Nikolajsen

---

On Thu, 1 Jan 2009 11:40:48 +0100, "P.E. Nikolajsen" <pen@akacia.dk>
wrote:

>Jeg har en tabel som giver mig et problem:
>
>Når jeg henter alt inholdet i tabelen (SELECT * FROM ...) virker det som
>forventet, men når jeg kun vil hente en enkelt record (SELECT * FROM ...
>WHERE x = '1') kommer der intet retur. Det er ligegyldigt hvilken felter i
>tabellen jeg søger på, resultatet er det samme.
>
>Nogen bud på hvad problemet skyldes?
>
>Poul Erik Nikolajsen

istedet for ... skriv navnet på tabellen

Steen

---

P.E. Nikolajsen wrote:
> Jeg har en tabel som giver mig et problem:
>
> Når jeg henter alt inholdet i tabelen (SELECT * FROM ...) virker det som
> forventet, men når jeg kun vil hente en enkelt record (SELECT * FROM ...
> WHERE x = '1') kommer der intet retur. Det er ligegyldigt hvilken felter
> i tabellen jeg søger på, resultatet er det samme.
>
> Nogen bud på hvad problemet skyldes?

Hvis der er matchende værdier, så skal rækkerne
findes.

Check for fejl beskeder.

Og check at det ikke er et problem med f.eks. trailing spaces.

Arne

---

"Arne Vajhøj" <arne@vajhoej.dk> skrev i meddelelsen
news:495ce52c$0$90269$14726298@news.sunsite.dk...
> P.E. Nikolajsen wrote:
>> Jeg har en tabel som giver mig et problem:
>>
>> Når jeg henter alt inholdet i tabelen (SELECT * FROM ...) virker det som
>> forventet, men når jeg kun vil hente en enkelt record (SELECT * FROM ...
>> WHERE x = '1') kommer der intet retur. Det er ligegyldigt hvilken felter
>> i tabellen jeg søger på, resultatet er det samme.
>>
>> Nogen bud på hvad problemet skyldes?
>
> Hvis der er matchende værdier, så skal rækkerne
> findes.
Enig, men det er det der ikke sker.

>
> Check for fejl beskeder.
Ingen.

>
> Og check at det ikke er et problem med f.eks. trailing spaces.
Ingen trailing spaces.

Søgning på tabellens numeriske værdi virker.
Søgninger tekst felter returnere ingen ting.


>
> Arne

---

P.E. Nikolajsen wrote:
> "Arne Vajhøj" <arne@vajhoej.dk> skrev i meddelelsen
> news:495ce52c$0$90269$14726298@news.sunsite.dk...
>> P.E. Nikolajsen wrote:
>>> Jeg har en tabel som giver mig et problem:
>>>
>>> Når jeg henter alt inholdet i tabelen (SELECT * FROM ...) virker det
>>> som forventet, men når jeg kun vil hente en enkelt record (SELECT *
>>> FROM ... WHERE x = '1') kommer der intet retur. Det er ligegyldigt
>>> hvilken felter i tabellen jeg søger på, resultatet er det samme.
>>>
>>> Nogen bud på hvad problemet skyldes?
>>
>> Hvis der er matchende værdier, så skal rækkerne
>> findes.
> Enig, men det er det der ikke sker.
>
>>
>> Check for fejl beskeder.
> Ingen.
>
>>
>> Og check at det ikke er et problem med f.eks. trailing spaces.
> Ingen trailing spaces.
>
> Søgning på tabellens numeriske værdi virker.
> Søgninger tekst felter returnere ingen ting.

Det ville jo nok være blevet observeret af andre hvis en af
verdens mest bruge databaser ikke kunne sammenligne tekst strenge.

Kan du copy paste noget SQL/PHP/whatever ind som viser
hvad du gør - gerne med lidt info om tabel strukturen
og output.

Arne

---

"Arne Vajhøj" <arne@vajhoej.dk> skrev i meddelelsen
news:495f852b$0$90265$14726298@news.sunsite.dk...
> P.E. Nikolajsen wrote:
>> "Arne Vajhøj" <arne@vajhoej.dk> skrev i meddelelsen
>> news:495ce52c$0$90269$14726298@news.sunsite.dk...
>>> P.E. Nikolajsen wrote:
>>>> Jeg har en tabel som giver mig et problem:
>>>>
>>>> Når jeg henter alt inholdet i tabelen (SELECT * FROM ...) virker det
>>>> som forventet, men når jeg kun vil hente en enkelt record (SELECT *
>>>> FROM ... WHERE x = '1') kommer der intet retur. Det er ligegyldigt
>>>> hvilken felter i tabellen jeg søger på, resultatet er det samme.
>>>>
>>>> Nogen bud på hvad problemet skyldes?
>>>
>>> Hvis der er matchende værdier, så skal rækkerne
>>> findes.
>> Enig, men det er det der ikke sker.
>>
>>>
>>> Check for fejl beskeder.
>> Ingen.
>>
>>>
>>> Og check at det ikke er et problem med f.eks. trailing spaces.
>> Ingen trailing spaces.
>>
>> Søgning på tabellens numeriske værdi virker.
>> Søgninger tekst felter returnere ingen ting.
>
> Det ville jo nok være blevet observeret af andre hvis en af
> verdens mest bruge databaser ikke kunne sammenligne tekst strenge.
>
> Kan du copy paste noget SQL/PHP/whatever ind som viser
> hvad du gør - gerne med lidt info om tabel strukturen
> og output.
>
> Arne

Tabellen er defineret således:

CREATE TABLE `sogne`
(
`Sogn_ID` integer (10) NOT NULL AUTO_INCREMENT ,
`Sogn` varchar (255),
`Herred` varchar (255),
`Amt` varchar (255),
PRIMARY KEY (`Sogn_ID`)
) TYPE=InnoDB CHARACTER SET latin1 COLLATE latin1_danish_ci

Dette virker

SELECT * FROM sogne WHERE sogn_id = '1'

og returner

1 Adslev Hjelmslev Skanderborg

Hvorimod

SELECT * FROM sogne WHERE sogn = 'Adslev'

intet returnere - det samme gør sig gældende hvis der søges på Herred og
Amt.

Jeg påstår ikke at det er en fejl i MySql. Jeg bruger MySql meget og laver
tilsvarende kald utallige steder, med fint resultat. Ergo må der være en
fejl i denne tabel, men hvilken?

---

Jeg er ikke mySQL-haj, men du kan få nogle generelle betragtninger.

P.E. Nikolajsen wrote:
> Tabellen er defineret således:
>
> CREATE TABLE `sogne`
> (
> `Sogn_ID` integer (10) NOT NULL AUTO_INCREMENT ,
> `Sogn` varchar (255),
> `Herred` varchar (255),
> `Amt` varchar (255),
> PRIMARY KEY (`Sogn_ID`)

Hvorfor alle disse `-tegn ?

> Dette virker
> SELECT * FROM sogne WHERE sogn_id = '1'

Normalt bruger man ikke ' til tal, kun til strenge.

> SELECT * FROM sogne WHERE sogn = 'Adslev'

Som Arne er inde på, så er den generelle definition på
CHAR(10) karakteriseret ved, at den altid er 10 karakterer, hvor databasen
indsætter de nødvendige trailing spaces,
hvorimod
VARCHAR(10) er karaktiseret ved, at den kun indeholder de aktuelle
karakterer.

Tidligere inkarnationer af MSSQL havde den egenskab, at 'de' ikke kunne
kende forskel på CHAR(x) og VARCHAR(x), som har givet anledning til en 'del
bøvl'.

Prøv
WHERE sogn >= 'Adslev'
eller
WHERE sogn LIKE 'Ads%'

--
Med venlig hilsen
Stig Johansen

---

> Jeg er ikke mySQL-haj, men du kan få nogle generelle betragtninger.
>
> P.E. Nikolajsen wrote:
>> Tabellen er defineret således:
>>
>> CREATE TABLE `sogne`
>> (
>> `Sogn_ID` integer (10) NOT NULL AUTO_INCREMENT ,
>> `Sogn` varchar (255),
>> `Herred` varchar (255),
>> `Amt` varchar (255),
>> PRIMARY KEY (`Sogn_ID`)
>
> Hvorfor alle disse `-tegn ?
>
>> Dette virker
>> SELECT * FROM sogne WHERE sogn_id = '1'
>
> Normalt bruger man ikke ' til tal, kun til strenge.
>
>> SELECT * FROM sogne WHERE sogn = 'Adslev'
>
> Som Arne er inde på, så er den generelle definition på
> CHAR(10) karakteriseret ved, at den altid er 10 karakterer, hvor databasen
> indsætter de nødvendige trailing spaces,
> hvorimod
> VARCHAR(10) er karaktiseret ved, at den kun indeholder de aktuelle
> karakterer.
>
> Tidligere inkarnationer af MSSQL havde den egenskab, at 'de' ikke kunne
> kende forskel på CHAR(x) og VARCHAR(x), som har givet anledning til en
> 'del
> bøvl'.
>
Der er tale MySql 5.0.45

> Prøv
> WHERE sogn >= 'Adslev'
> eller
> WHERE sogn LIKE 'Ads%'
>
Har prøvet begge dele uden resultat

---

Stig Johansen wrote:
> Jeg er ikke mySQL-haj, men du kan få nogle generelle betragtninger.
>
> P.E. Nikolajsen wrote:
>> Tabellen er defineret således:
>>
>> CREATE TABLE `sogne`
>> (
>> `Sogn_ID` integer (10) NOT NULL AUTO_INCREMENT ,
>> `Sogn` varchar (255),
>> `Herred` varchar (255),
>> `Amt` varchar (255),
>> PRIMARY KEY (`Sogn_ID`)
>
> Hvorfor alle disse `-tegn ?

Det er en uskik som er ret almindelig i MySQL verdenen
også i tools der genererer SQL. De gør at man
kan bruge reserverede ord som navne og have navne med
mellemrum etc.. D.v.s. at `` i MySQL svarer til [] i
SQLServer.

>> Dette virker
>> SELECT * FROM sogne WHERE sogn_id = '1'
>
> Normalt bruger man ikke ' til tal, kun til strenge.

MySQL er mere tolerant med hensyn til den slags end
andre databaser. Det virker faktisk. Jeg ville aldrig
bruge dem.

Arne

---

Arne Vajhøj wrote:

> D.v.s. at `` i MySQL svarer til [] i
> SQLServer.

Ok, så det er en form for vendor lockin ?
Hvorfor bruger man ikke " som, SVJH, er SQL Ansi standard (Jeg ved godt
hvorfor MS skiftede fra " til [] fra 6.5->7.0, men hvad er mySQL's
motivation)?

>>> SELECT * FROM sogne WHERE sogn_id = '1'
>>
>> Normalt bruger man ikke ' til tal, kun til strenge.
>
> MySQL er mere tolerant med hensyn til den slags end
> andre databaser. Det virker faktisk.

Jeg ved ikke om det er godt eller skidt.
Jeg er personligt ikke særlig glad for at 'databasen' skal fortolke mine
udtryk, med deraf følgende risiko for manglende præcision i data.

> Jeg ville aldrig
> bruge dem.

Ditto.

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen wrote:
> Arne Vajhøj wrote:
>> D.v.s. at `` i MySQL svarer til [] i
>> SQLServer.
>
> Ok, så det er en form for vendor lockin ?

Faktisk ja.

> Hvorfor bruger man ikke " som, SVJH, er SQL Ansi standard

Traditionelt har MySQL brugt "abc" som synonym for 'abc'.

Man kan enable ANSI_QUOTES option, men kompabilitet bla.bla..

>>>> SELECT * FROM sogne WHERE sogn_id = '1'
>>> Normalt bruger man ikke ' til tal, kun til strenge.
>> MySQL er mere tolerant med hensyn til den slags end
>> andre databaser. Det virker faktisk.
>
> Jeg ved ikke om det er godt eller skidt.
> Jeg er personligt ikke særlig glad for at 'databasen' skal fortolke mine
> udtryk, med deraf følgende risiko for manglende præcision i data.

Jeg synes at det er skidt.

Men sådan er det.

Arne

---

Stig Johansen wrote:
> Hvorfor bruger man ikke " som, SVJH, er SQL Ansi standard (Jeg ved godt
> hvorfor MS skiftede fra " til [] fra 6.5->7.0, men hvad er mySQL's
> motivation)?

Hvorfor gjorde MS det?

--
Lars Kongshøj

---

Lars Kongshøj wrote:

> Stig Johansen wrote:
>> Hvorfor bruger man ikke " som, SVJH, er SQL Ansi standard (Jeg ved godt
>> hvorfor MS skiftede fra " til [] fra 6.5->7.0, men hvad er mySQL's
>> motivation)?
>
> Hvorfor gjorde MS det?

Ved at indsylte alt muligt genereret SQL i [], sikrer man sig, at når der er
tilstrækkeligt meget af den slags i programmerne, er det (stort set)
umuligt at skifte database.

7.0 kunne godt håndtere standard "'er, men man skulle konfigurere det
manuelt, og det var disabled ved installation/upgrade 6.5->7.0

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen wrote:
> Lars Kongshøj wrote:
>> Stig Johansen wrote:
>>> Hvorfor bruger man ikke " som, SVJH, er SQL Ansi standard (Jeg ved godt
>>> hvorfor MS skiftede fra " til [] fra 6.5->7.0, men hvad er mySQL's
>>> motivation)?
>> Hvorfor gjorde MS det?
>
> Ved at indsylte alt muligt genereret SQL i [], sikrer man sig, at når der er
> tilstrækkeligt meget af den slags i programmerne, er det (stort set)
> umuligt at skifte database.

Har du en email fra Bill Gates der dokumenterer det ?

Siden du nu "ved" det og ikke bare "gætter" på det.

Arne

---

Arne Vajhøj wrote:

> Har du en email fra Bill Gates der dokumenterer det ?
>
> Siden du nu "ved" det og ikke bare "gætter" på det.

He - ordkløver ?
Hvad skulle baggrunden ellers være ?

Jeg er pissesur på Bill over det nummer.
Der var en af mine kunder, der havde opgraderet sin MS SQLServer fra 6.5q ->
7.0 uden jeg vidste det.

Visse steder havde jeg brugt ", og det medførte, at mit program pludselig
gav database fejl.

Det kostede en tur - retur til Jylland, og adskillige timer inden jeg fandt
ud af hans lille 'narrestreg'.

Kunden havde ikke teknisk indsigt til at forstå qproblemet - "Det var jo mit
program der fejler".

Så jeg måtte selv æde transport, timer osv.

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen wrote:
> Arne Vajhøj wrote:
>> Har du en email fra Bill Gates der dokumenterer det ?
>>
>> Siden du nu "ved" det og ikke bare "gætter" på det.
>
> He - ordkløver ?
> Hvad skulle baggrunden ellers være ?

Tja - jeg forslog jo i en anden post, at det kunne være af
hensyn til MS Access kompabilitet.

Arne

---

Arne Vajhøj wrote:

> Stig Johansen wrote:
>> Hvad skulle baggrunden ellers være ?
>
> Tja - jeg forslog jo i en anden post, at det kunne være af
> hensyn til MS Access kompabilitet.

Lad os se bort fra jeg brugte ordet 'ved' i stedet for 'tror jeg ved'.

Access var ikke særligt udbredt i virksomhederne.
Det var ikke en del af Office pakken, og skulle købes separat, til visnok
3-4.000 pr. bruger, så den blev kun brugt af de få indviede (super) brugere
til nogle hjemmestrikket fedtemadsprogrammer.

MS SQLServer var ikke deres eget produkt, men et køb/licens af Sybase.
Til og med 6.5 lignede den nok Sybase for meget i MS's smag.

Analogt med Internet Explorer med HTML og JScript, så 'bøjer man'
standarderne.

Brug af " til identifiers, og ' til literals er SVJV SQL ANSI Standard.

Man fjerner MAO bevidst understøttelse af standard til fordel for sin egen
'standard'.

Hvis man havde rent mel i posen, ville jeg tro man ville ændre Access til at
understøtte standard i stedet.

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen wrote:
> Arne Vajhøj wrote:
>> Stig Johansen wrote:
>>> Hvad skulle baggrunden ellers være ?
>> Tja - jeg forslog jo i en anden post, at det kunne være af
>> hensyn til MS Access kompabilitet.
>
> Lad os se bort fra jeg brugte ordet 'ved' i stedet for 'tror jeg ved'.
>
> Access var ikke særligt udbredt i virksomhederne.

Access var skam ret udbredt også dengang.

> Det var ikke en del af Office pakken, og skulle købes separat, til visnok
> 3-4.000 pr. bruger,

Bl.a. fordi den var en del af Office 95, 97 og 2000 i Professional
udgaven.

> så den blev kun brugt af de få indviede (super) brugere
> til nogle hjemmestrikket fedtemadsprogrammer.

De "hjemmestrikkede fedtemadsprogrammer" blev nogen gange så store
at det var nødvendigt at upsize dem til SQLServer.

> Brug af " til identifiers, og ' til literals er SVJV SQL ANSI Standard.

Det er korrekt.

> Man fjerner MAO bevidst understøttelse af standard til fordel for sin egen
> 'standard'.
>
> Hvis man havde rent mel i posen, ville jeg tro man ville ændre Access til at
> understøtte standard i stedet.

Eller man har lavet en business vurdering af at det var nemmere at lære
SQLServer DBA'ere at bruge SET QUOTED_IDENTIFIER ON end at lære Access
folkene at bruge "".

Arne

---

Arne Vajhøj wrote:

> Stig Johansen wrote:
>> Access var ikke særligt udbredt i virksomhederne.
>
> Access var skam ret udbredt også dengang.

Jeg må hellere præcisere: "De virksomheder jeg lavede opgaver for".
Det var typisk store produktionsvirksomheder, der kørte deres operastionelle
systemer på en mini/main-frame platform.

Et typisk scenaria var, at økonomichefer/direktører sad med nogle 'monster'
regneark, Lotus 123 eller Excel, og ikke Access.

>> Det var ikke en del af Office pakken, og skulle købes separat, til visnok
>> 3-4.000 pr. bruger,
>
> Bl.a. fordi den var en del af Office 95, 97 og 2000 i Professional
> udgaven.

Jeg har været med i 'gamet' siden 1980, og årtal og versioner flyder lidt
ud.
På et tidspunkt blev Access en del af Officepakken, men jeg husker ikke
hvilken version.
Ydermere kører disse kunder på Select aftaler, som ikke nødvendigvis er
samme struktur som i detailhandel.

Med udbredt mener jeg også brugt, og ikke kun installeret.

>> så den blev kun brugt af de få indviede (super)
>> brugere
>> til nogle hjemmestrikket fedtemadsprogrammer.
>
> De "hjemmestrikkede fedtemadsprogrammer" blev nogen gange så store
> at det var nødvendigt at upsize dem til SQLServer.

Ikke i de virksomheder jeg kender.
Kritiske data ligger på 'det store jern', og MS SQLServer kommer ind i
billedet til små sidesystemer som Datawarehouse/BI systemer.

> Eller man har lavet en business vurdering af at det var nemmere at lære
> SQLServer DBA'ere at bruge SET QUOTED_IDENTIFIER ON end at lære Access
> folkene at bruge "".

Det tvivler jeg som sagt på, men enhver kan tro hvad man vil.

Baggrunden for at købe Sybase var for at komme in på databasemarkedet og
prøve at 'lege med de store'.

--
Med venlig hilsen
Stig Johansen

---

Lars Kongshøj wrote:
> Stig Johansen wrote:
>> Hvorfor bruger man ikke " som, SVJH, er SQL Ansi standard (Jeg ved godt
>> hvorfor MS skiftede fra " til [] fra 6.5->7.0, men hvad er mySQL's
>> motivation)?
>
> Hvorfor gjorde MS det?

En mulig forklaring er er at MS Access (Jet) brugte [] og at
de gerne ville gøre det nemmere at skifte fra MS Access til
SQLServer.

Arne

---

Arne Vajhøj wrote:

> En mulig forklaring er er at MS Access (Jet) brugte [] og at
> de gerne ville gøre det nemmere at skifte fra MS Access til
> SQLServer.

Hvis man holder sig fra 'mærkeliqe' navne, behøver hverken Access eller MS
SQLServer de der [].

og mySQL behøver heller ikke de der `

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen wrote:
> Arne Vajhøj wrote:
>> En mulig forklaring er er at MS Access (Jet) brugte [] og at
>> de gerne ville gøre det nemmere at skifte fra MS Access til
>> SQLServer.
>
> Hvis man holder sig fra 'mærkeliqe' navne, behøver hverken Access eller MS
> SQLServer de der [].
>
> og mySQL behøver heller ikke de der `

Det er vi helt enige om.

Desværre mangler vi at overbevise et par stykker.

Arne

PS: Det er ikke kun navne med mellemrum i (som jeg antager er
hvad du mener med "mærkelige"), men også brug af reserverede
ord som navne, det bruges til - men det ene er jo lige så slemt som
det andet.

---

Arne Vajhøj wrote:
> En mulig forklaring er er at MS Access (Jet) brugte [] og at
> de gerne ville gøre det nemmere at skifte fra MS Access til
> SQLServer.

Det er da ingen begrundelse for at fjerne understøttelsen af standard.
Det er intet problem at have to skrivemåder for sammen leksem, det er
der masser af eksempler på.

--
Lars Kongshøj

---

Lars Kongshøj wrote:
> Arne Vajhøj wrote:
>> En mulig forklaring er er at MS Access (Jet) brugte [] og at
>> de gerne ville gøre det nemmere at skifte fra MS Access til
>> SQLServer.
>
> Det er da ingen begrundelse for at fjerne understøttelsen af standard.
> Det er intet problem at have to skrivemåder for sammen leksem, det er
> der masser af eksempler på.

Der er den lille krølle at Access udover ikke at bruge "" omkring
navne faktisk bruger "" som string literal (ligesom '').

De to brug af "" er ikke kompatible.

Og SQLServer understøtter skam stadig "" omkring navne.

SET QUOTED_IDENTIFIER ON

eller den tilsvarende sp_dboption kan enable muligheden.

Arne

---

P.E. Nikolajsen wrote:
> "Arne Vajhøj" <arne@vajhoej.dk> skrev i meddelelsen
>> Kan du copy paste noget SQL/PHP/whatever ind som viser
>> hvad du gør - gerne med lidt info om tabel strukturen
>> og output.
>
> Tabellen er defineret således:
>
> CREATE TABLE `sogne`
> (
> `Sogn_ID` integer (10) NOT NULL AUTO_INCREMENT ,
> `Sogn` varchar (255),
> `Herred` varchar (255),
> `Amt` varchar (255),
> PRIMARY KEY (`Sogn_ID`)
> ) TYPE=InnoDB CHARACTER SET latin1 COLLATE latin1_danish_ci
>
> Dette virker
>
> SELECT * FROM sogne WHERE sogn_id = '1'
>
> og returner
>
> 1 Adslev Hjelmslev Skanderborg
>
> Hvorimod
>
> SELECT * FROM sogne WHERE sogn = 'Adslev'
>
> intet returnere - det samme gør sig gældende hvis der søges på Herred og
> Amt.

Hvad viser:

SELECT CONCAT('#',sogn,'#'),CONCAT('#',herred,'#'),CONCAT('#',amt,'#')
FROM sogne WHERE sogn_id = 1

?

Arne

---

Fejlen fundet:
Der VAR en blank karakter først i felterne, som jeg ikke kunne se.

Tak for hjælpen.

PE
"Arne Vajhøj" <arne@vajhoej.dk> skrev i meddelelsen
news:4960bfb1$0$90270$14726298@news.sunsite.dk...
> P.E. Nikolajsen wrote:
>> "Arne Vajhøj" <arne@vajhoej.dk> skrev i meddelelsen
>>> Kan du copy paste noget SQL/PHP/whatever ind som viser
>>> hvad du gør - gerne med lidt info om tabel strukturen
>>> og output.
>>
>> Tabellen er defineret således:
>>
>> CREATE TABLE `sogne`
>> (
>> `Sogn_ID` integer (10) NOT NULL AUTO_INCREMENT ,
>> `Sogn` varchar (255),
>> `Herred` varchar (255),
>> `Amt` varchar (255),
>> PRIMARY KEY (`Sogn_ID`)
>> ) TYPE=InnoDB CHARACTER SET latin1 COLLATE latin1_danish_ci
>>
>> Dette virker
>>
>> SELECT * FROM sogne WHERE sogn_id = '1'
>>
>> og returner
>>
>> 1 Adslev Hjelmslev Skanderborg
>>
>> Hvorimod
>>
>> SELECT * FROM sogne WHERE sogn = 'Adslev'
>>
>> intet returnere - det samme gør sig gældende hvis der søges på Herred og
>> Amt.
>
> Hvad viser:
>
> SELECT CONCAT('#',sogn,'#'),CONCAT('#',herred,'#'),CONCAT('#',amt,'#')
> FROM sogne WHERE sogn_id = 1
>
> ?
>
> Arne

---

P.E. Nikolajsen wrote:
> "Arne Vajhøj" <arne@vajhoej.dk> skrev i meddelelsen
> news:4960bfb1$0$90270$14726298@news.sunsite.dk...
>> P.E. Nikolajsen wrote:
>>> "Arne Vajhøj" <arne@vajhoej.dk> skrev i meddelelsen
>>>> Kan du copy paste noget SQL/PHP/whatever ind som viser
>>>> hvad du gør - gerne med lidt info om tabel strukturen
>>>> og output.
>>>
>>> Tabellen er defineret således:
>>>
>>> CREATE TABLE `sogne`
>>> (
>>> `Sogn_ID` integer (10) NOT NULL AUTO_INCREMENT ,
>>> `Sogn` varchar (255),
>>> `Herred` varchar (255),
>>> `Amt` varchar (255),
>>> PRIMARY KEY (`Sogn_ID`)
>>> ) TYPE=InnoDB CHARACTER SET latin1 COLLATE latin1_danish_ci
>>>
>>> Dette virker
>>>
>>> SELECT * FROM sogne WHERE sogn_id = '1'
>>>
>>> og returner
>>>
>>> 1 Adslev Hjelmslev Skanderborg
>>>
>>> Hvorimod
>>>
>>> SELECT * FROM sogne WHERE sogn = 'Adslev'
>>>
>>> intet returnere - det samme gør sig gældende hvis der søges på Herred
>>> og Amt.
>>
>> Hvad viser:
>>
>> SELECT CONCAT('#',sogn,'#'),CONCAT('#',herred,'#'),CONCAT('#',amt,'#')
>> FROM sogne WHERE sogn_id = 1

> Fejlen fundet:
> Der VAR en blank karakter først i felterne, som jeg ikke kunne se.



Det er nemt at trimme felterne med:

UPDATE sogne SET sogn=TRIM(sogn),herred=TRIM(herred),amt=TRIM(amt)

Arne

---

"Arne Vajhøj" <arne@vajhoej.dk> skrev i meddelelsen
news:4961217c$0$90270$14726298@news.sunsite.dk...
> P.E. Nikolajsen wrote:
>> "Arne Vajhøj" <arne@vajhoej.dk> skrev i meddelelsen
>> news:4960bfb1$0$90270$14726298@news.sunsite.dk...
>>> P.E. Nikolajsen wrote:
>>>> "Arne Vajhøj" <arne@vajhoej.dk> skrev i meddelelsen
>>>>> Kan du copy paste noget SQL/PHP/whatever ind som viser
>>>>> hvad du gør - gerne med lidt info om tabel strukturen
>>>>> og output.
>>>>
>>>> Tabellen er defineret således:
>>>>
>>>> CREATE TABLE `sogne`
>>>> (
>>>> `Sogn_ID` integer (10) NOT NULL AUTO_INCREMENT ,
>>>> `Sogn` varchar (255),
>>>> `Herred` varchar (255),
>>>> `Amt` varchar (255),
>>>> PRIMARY KEY (`Sogn_ID`)
>>>> ) TYPE=InnoDB CHARACTER SET latin1 COLLATE latin1_danish_ci
>>>>
>>>> Dette virker
>>>>
>>>> SELECT * FROM sogne WHERE sogn_id = '1'
>>>>
>>>> og returner
>>>>
>>>> 1 Adslev Hjelmslev Skanderborg
>>>>
>>>> Hvorimod
>>>>
>>>> SELECT * FROM sogne WHERE sogn = 'Adslev'
>>>>
>>>> intet returnere - det samme gør sig gældende hvis der søges på Herred
>>>> og Amt.
>>>
>>> Hvad viser:
>>>
>>> SELECT CONCAT('#',sogn,'#'),CONCAT('#',herred,'#'),CONCAT('#',amt,'#')
>>> FROM sogne WHERE sogn_id = 1
>
>> Fejlen fundet:
>> Der VAR en blank karakter først i felterne, som jeg ikke kunne se.
>
>
>
> Det er nemt at trimme felterne med:
>
> UPDATE sogne SET sogn=TRIM(sogn),herred=TRIM(herred),amt=TRIM(amt)
>
> Arne

Jeps, er gjort.

PE

---

P.E. Nikolajsen wrote:

> "Arne Vajhøj" <arne@vajhoej.dk> skrev i meddelelsen
>> Det er nemt at trimme felterne med:
>>
>> UPDATE sogne SET sogn=TRIM(sogn),herred=TRIM(herred),amt=TRIM(amt)
>>
>> Arne
>
> Jeps, er gjort.

Bare lige et råd.
Find ud af hvordan felterne er blevet oprettet med leading spaces.
Og ret det dér.

--
Med venlig hilsen
Stig Johansen