[SQL] Lengte telefoonnummers checken

[Multensor]

Ik wil d.m.v. een sql checken of er bestaande telefoonnummers ingevoerd zijn dus: 4 + 6 of 3+7 of 2+8(gsm). Ook wil ik checken of het 1e cijfer een 0 is. Nu heb ik de volgende query gemaakt alleen geeft hij ook de goede telefoonnummers weer.

p.s. ik werk in acces 2003

SELECT V.Vertegenwoordigernaam, V.Netnr, V.Abonneenr
FROM tblVertegenwoordiger AS V
WHERE (((Len([V.netnr]))=2) And ((Len([V.abonneenr]))<>8)) Or (((Len([V.netnr]))=3) And ((Len([V.abonneenr]))<>7)) Or (((Len([V.netnr]))=4) And ((Len([V.abonneenr]))<>6)) Or (((Mid([V.netnr],1,1))<>0));

[Boss]

Heb je serieus 2 velden aangemaakt voor abonneenr en netnr? Wat is daar het voordeel van, behalve dat het je nu extra werk geeft om te controleren of een nummer gewoon 10 karakters is?

[curry684]

Kun je wellicht iets meer aandacht aan je topicstart besteden zodat we feitelijk begrijpen waarop je wil filteren? Like, '4+6 of 3+7 of 2+8' is geheimtaal voor mij hoor, en naar ik mag aannemen voor de meeste anderen Het zou ook helpen als je feitelijk aan zou geven waarop je vermoed dat je query niet werkt en zo, en je zou 'm voor de leesbaarheid in [code=sql] tags kunnen plaatsen

[Multensor]

curry684 schreef op woensdag 26 januari 2005 @ 09:51:
Kun je wellicht iets meer aandacht aan je topicstart besteden zodat we feitelijk begrijpen waarop je wil filteren? Like, '4+6 of 3+7 of 2+8' is geheimtaal voor mij hoor, en naar ik mag aannemen voor de meeste anderen Het zou ook helpen als je feitelijk aan zou geven waarop je vermoed dat je query niet werkt en zo, en je zou 'm voor de leesbaarheid in [code=sql] tags kunnen plaatsen

Ok nou het 4+6 verhaal slaat dus er dus op dat als je 4 cijfers als netnr hebt dan moet het abonneenr 6 cijfers zijn en bij 3 cijfers netnr moet het 7 cijfers abonneenr hebben. (hoop dat dat beetje duidelijk is )

Ik denk zelf dat er iets fout zit bij de len functie maar ik weer niet precies wat.

[marty]

kent access geen regular expressions?
en ja, het is idd wel onhandig dat je het telefoonnummer heb opgesplits lijkt me.

[curry684]

Boss schreef op woensdag 26 januari 2005 @ 09:49:
Heb je serieus 2 velden aangemaakt voor abonneenr en netnr? Wat is daar het voordeel van, behalve dat het je nu extra werk geeft om te controleren of een nummer gewoon 10 karakters is?

Aha dus dat bedoelt ie met 4+6 etc.

Nou dat is sowieso onzin, want [phone] is helemaal geen 10 karakters, evenmin als [phone] of 0900-8844. De hele aanpak is dus grofstoffelijk fout

[OZ-Gump]

Mijn eerste gevoel bij jouw vraag is: als het telefoonnummer niet goed is, waarom zou je het dan opslaan in je database? Controleer bij inserten in de database of het nummer in orde is en zo niet: niet accepteren.

Over optimalisatie is ook nog te praten, omdat je nu zes keer per record een len uitrekent. Drie keer over netnummer en drie keer over aboneenummer. Misschien is het makkelijker deze in een subquery eenmalig per record uit te rekenen en die velden te gebruiken in de where.

Ontopic:
Je haakjes lijken goed te staan, maar je vergelijkt de uitkomst van de mid (die een string teruggeeft) met een integer. Zet eens dubbele quotes rondom de 0???
_{Mid([V.netnr],1,1) <> "0"}

[ Voor 3% gewijzigd door OZ-Gump op 26-01-2005 09:57 ]

[Maasluip]

Waarom doe je niet iets als

code:

WHERE Len([V.netnr]) + Len([V.abonneenr]) <> 10
AND Len([V.netnr]) NOT IN (2,3,4)

(niet zeker of NOT IN in access kan.

[Multensor]

marty schreef op woensdag 26 januari 2005 @ 09:54:
kent access geen regular expressions?
en ja, het is idd wel onhandig dat je het telefoonnummer heb opgesplits lijkt me.

Het is schoolwerk en ik moet de database laten zoals ie is . Vond het zelf ook erg onhandig maja mag er dus niets aan veranderen.

[JJvG]

Input moet je niet controleren in je database, maar voordat het je database in komt. Schrijf er een functie voor in Access of ASP (waar je mee werkt). Scheiding van lagen (gui - logica - data) is het idee. Je database doet niets anders dan het opslaan op een goed genormaliseerde manier. Uit je database laten dus!

Daarnaast lijkt me de splitsing van netnr/abonneenr niet handig. Wat als je buitenlandse nummers hebt (die langer of korter kunnen zijn)?

[curry684]

Print dit topic maar uit en toon maar aan je docent dat de mensen die wel verstand van zaken hebben vinden dat ie een idioot slechte database heeft ontworpen

Anyway, als de combinatie altijd 10 moet zijn tel je gewoon de lengtes op ja, en in je huidige query is de MID-clause aan het einde altijd true waardoor de hele WHERE-clause altijd true wordt

[Multensor]

Maasluip schreef op woensdag 26 januari 2005 @ 09:55:
Waarom doe je niet iets als

code:

WHERE Len([V.netnr]) + Len([V.abonneenr]) <> 10
AND Len([V.netnr]) NOT IN (2,3,4)

(niet zeker of NOT IN in access kan.

Als ik het zo invoer komt er niks uit. Deze had ik ook al geprobeerd maar hij geeft nu dus helemaal geen resultaten terwijl er wel foute telefoonnummers in staan.

[curry684]

OZ-Gump schreef op woensdag 26 januari 2005 @ 09:54:
_{Mid([V.netnr],1,1) <> "0"}

SQL:

left([V.netnr], 1) <> '0'

....

[OZ-Gump]

* OZ-Gump wijst naar de twee drie keer dat het antwoord al gegeven is

*kuch* MID _{of left} *kuch*

[ Voor 20% gewijzigd door OZ-Gump op 26-01-2005 10:01 . Reden: ;) ]

[curry684]

Maasluip schreef op woensdag 26 januari 2005 @ 09:55:
Waarom doe je niet iets als

code:

WHERE Len([V.netnr]) + Len([V.abonneenr]) <> 10
AND Len([V.netnr]) NOT IN (2,3,4)

(niet zeker of NOT IN in access kan.

Dat moet een OR zijn trouwens ipv AND.

[Multensor]

met de

SQL:

left([V.netnr], 1) <> '0'

geeft de query nog steeds alle resultaten (goede en slechte telefoonnummers)

[ Voor 12% gewijzigd door Multensor op 26-01-2005 10:06 ]

[OZ-Gump]

Als jij je volledige query hier hebt neergezet en jouw idee van een 'goed' telefoonnummer gelijk staat aan datgene wat je in je query doet... dan kan dat niet. Copy & paste je query eens letterlijk, voer hem eens uit in Access zelf, bekijk de returnvalues, neem eventueel de len-waardes even mee in de select zodat je ziet wat daar gebeurt, oftewel: debug!

Breng ons ook even op de hoogte, dan kunnen we je helpen als het nodig is.

[curry684]

Multensor schreef op woensdag 26 januari 2005 @ 10:06:
met de

SQL:

left([V.netnr], 1) <> '0'

geeft de query nog steeds alle resultaten (goede en slechte telefoonnummers)

Je geeft wel lekker veel info he

SQL:

SELECT V.Vertegenwoordigernaam, V.Netnr, V.Abonneenr
FROM tblVertegenwoordiger AS V
WHERE Len([V.netnr]) + Len([V.abonneenr]) <> 10
OR Len([V.netnr]) NOT IN (2,3,4)
OR left([V.netnr], 1) <> '0'

Met deze query ben ik toch wel heel benieuwd welk goed telefoonnummer er nog doorheen komt.

[OZ-Gump]

curry684 schreef op woensdag 26 januari 2005 @ 10:15:

SQL:

SELECT V.Vertegenwoordigernaam, V.Netnr, V.Abonneenr
FROM tblVertegenwoordiger AS V
WHERE Len([V.netnr]) + Len([V.abonneenr]) <> 10
OR Len([V.netnr]) NOT IN (2,3,4)
OR left([V.netnr], 1) <> '0'

Met deze query ben ik toch wel heel benieuwd welk goed telefoonnummer er nog doorheen komt.

Ik voel een telefoonnummer met een leesteken aankomen ...

Multensor: geef ons even wat meer info dan te zeggen dat hij het niet doet. Dat schiet natuurlijk niet echt op.

[Multensor]

curry684 schreef op woensdag 26 januari 2005 @ 10:15:
[...]

Je geeft wel lekker veel info he

SQL:

SELECT V.Vertegenwoordigernaam, V.Netnr, V.Abonneenr
FROM tblVertegenwoordiger AS V
WHERE Len([V.netnr]) + Len([V.abonneenr]) <> 10
OR Len([V.netnr]) NOT IN (2,3,4)
OR left([V.netnr], 1) <> '0'

Met deze query ben ik toch wel heel benieuwd welk goed telefoonnummer er nog doorheen komt.

Als ik heel eerlijk ben komen weer alle goede telefoonnummers er doorheen . Alleen bedacht ik me net dat de kolommen netr en abonneenr niet numeriek zijn maar gewoon tekst (als ik ze op numeriek zet dan verdwijnt de 1e 0 en heb je dus nooit een 4-cijferig netnr). Mayb dat dit er iets mee te maken kan hebben ?

Multensor: geef ons even wat meer info dan te zeggen dat hij het niet doet. Dat schiet natuurlijk niet echt op.

jah ik wil wel info geven maar ik heb geen idee aan wat voor info je hulp hebt . * Multensor werkt niet zo vaak met sql en databases.

[ Voor 16% gewijzigd door Multensor op 26-01-2005 10:22 ]

[curry684]

Multensor schreef op woensdag 26 januari 2005 @ 10:20:
[...]

Als ik heel eerlijk ben komen weer alle goede telefoonnummers er doorheen . Alleen bedacht ik me net dat de kolommen netr en abonneenr niet numeriek zijn maar gewoon tekst (als ik ze op numeriek zet dan verdwijnt de 1e 0 en heb je dus nooit een 4-cijferig netnr). Mayb dat dit er iets mee te maken kan hebben ?

curry684 schreef op maandag 24 januari 2005 @ 00:33:
Je mag een telefoonnummer per definitie niet als een integer opslaan omdat de leading zero nationaal relevant is, en je internationaal soms zelfs 2 leading zeroes nodig hebt. Deze zijn echter niet portable en worden dus met een plusje weergegeven, waardoor [phone] een geldig telefoonnummer is. Veel plezier met dat in een integer te stoppen

Essentie is dat een integer bedoeld is voor velden die een waarde cq. hoeveelheid representeren. Een telefoonnummer is enkel een sequentie van cijfers die samen een unieke code vormen, dat maakt het nog geen 'waarde'. Ergo de correcte representatie is wel degelijk een string.

[...]

jah ik wil wel info geven maar ik heb geen idee aan wat voor info je hulp hebt

Like anything dat nuttiger is dan 'hijdoetutnie'?

[OZ-Gump]

Heb je de len's al eens in je select gezet, zodat je ze zichtbaar hebt? Heb je al eens gekeken welke combinaties van net- en abonneenummer er nou doorkomen? Heb je het al eens geprobeerd met eerst een klein stukje van de where, en dan steeds meer toevoegen, zodat je er misschien achter komt waar het misgaat? Heb je de tabelstructuur nog eens goed bekeken?

Post die informatie dan ook eens! Zonder info wordt het enorm moeilijk om je te helpen. Da's hetzelfde als je auto een garage binnenrijden en dan zeggen: "hij is kapot" om vervolgens weer te vertrekken. En het dan raar vinden dat je mistlicht nog steeds niet werkt als je terugkomt

[Ecto2002]

Als het dan toch tekst is, zou ik voor alle zekerheid de leading en trailing spaties eruit halen met de Trim-functie (mss een beetje beroepsmisvorming, maar ik ben meer met SQL Server bezig).

Kleine noot : Als je slechts 1 tabel gebruikt in een SQL statement, is het overbodig een alias te gebruiken.

code:

SELECT Vertegenwoordigernaam, Netnr, Abonneenr
FROM tblVertegenwoordiger
WHERE Len(Trim([netnr])) + Len(Trim([abonneenr])) <> 10
OR Len(trim([netnr])) NOT IN (2,3,4)
OR left(Trim([netnr]), 1) <> '0'

Edit : Graag gedaan

[ Voor 6% gewijzigd door Ecto2002 op 26-01-2005 10:49 ]

[Multensor]

OZ-Gump schreef op woensdag 26 januari 2005 @ 10:27:
Heb je de len's al eens in je select gezet, zodat je ze zichtbaar hebt? Heb je al eens gekeken welke combinaties van net- en abonneenummer er nou doorkomen? Heb je het al eens geprobeerd met eerst een klein stukje van de where, en dan steeds meer toevoegen, zodat je er misschien achter komt waar het misgaat? Heb je de tabelstructuur nog eens goed bekeken?

Post die informatie dan ook eens! Zonder info wordt het enorm moeilijk om je te helpen. Da's hetzelfde als je auto een garage binnenrijden en dan zeggen: "hij is kapot" om vervolgens weer te vertrekken. En het dan raar vinden dat je mistlicht nog steeds niet werkt als je terugkomt

Heb je al eens gekeken welke combinaties van net- en abonneenummer er nou doorkomen?-->Elke combinatie komt er momenteel doorheen.

Als ik het volgende probeer:

SQL:

SELECT V.Vertegenwoordigernaam, V.Netnr, V.Abonneenr
FROM tblVertegenwoordiger AS V
WHERE (((Len([V.netnr]))=2) And ((Len([V.abonneenr]))<>8));

Dan geeft de query niets weer terwijl er 06 423448 in de database staat. Dus deze opdracht werkt al niet eens.

Heb je de len's al eens in je select gezet, zodat je ze zichtbaar hebt?--> hij zegt dat ik bij netnr overal 4 heb, maar er staat 4 netnr waarvan er maar 2 4-cijferig zijn dus dit klotp niet. Ook bij abonneenr zegt de query dat ze allemaal 8 zijn, maar ook hier staan verschillende lengtes in de tabel .

[Multensor]

Ecto2002 schreef op woensdag 26 januari 2005 @ 10:36:
Als het dan toch tekst is, zou ik voor alle zekerheid de leading en trailing spaties eruit halen met de Trim-functie (mss een beetje beroepsmisvorming, maar ik ben meer met SQL Server bezig).

Kleine noot : Als je slechts 1 tabel gebruikt in een SQL statement, is het overbodig een alias te gebruiken.

code:

SELECT Vertegenwoordigernaam, Netnr, Abonneenr
FROM tblVertegenwoordiger
WHERE Len(Trim([netnr])) + Len(Trim([abonneenr])) <> 10
OR Len(trim([netnr])) NOT IN (2,3,4)
OR left(Trim([netnr]), 1) <> '0'

Ok volgens mij heb jij de koelkast gewonnen . Ik ga nog even testen of het werkt met verschillende telefoonnummers.

Jaja getest en wel werkt het op alle manieren waarvan ik dat wil. Allen bedankt voor jullie hulp.

[ Voor 9% gewijzigd door Multensor op 26-01-2005 10:41 ]

[OZ-Gump]

Ok volgens mij heb jij de koelkast gewonnen

Dat zou willen betekenen dat je niet alleen verkeerde data in je database opslaat (wat je al niet wil) maar dat je deze data bij het in de database plaatsen ook nog eens verder gaat vernaggelen door er spaties achter te plakken...?

Overigens was dit er ook uitgekomen als je had gekeken naar datgene wat er uit je query kwam. Een simpele klik op een uitkomstveld had je namelijk vast wel op de spaties in je velden gewezen...

[curry684]

Spacepadding in databasefields

[Boss]

curry684 schreef op woensdag 26 januari 2005 @ 10:49:
Spacepadding in databasefields

Was vroeger heel normaal toch

[curry684]

Boss schreef op woensdag 26 januari 2005 @ 13:34:
[...]

Was vroeger heel normaal toch

In 1980 ja

[Verwijderd]

Multensor schreef op woensdag 26 januari 2005 @ 10:39:
[...]


Ok volgens mij heb jij de koelkast gewonnen . Ik ga nog even testen of het werkt met verschillende telefoonnummers.

Jaja getest en wel werkt het op alle manieren waarvan ik dat wil. Allen bedankt voor jullie hulp.

[phone] wordt dus wel geweigerd terwijl het een legaal nummer is. Maar het blijft natuurlijk een schoolopdracht.