|
| reverse opslag i alfabetisk orden Fra : Arne Feldborg |
Dato : 21-03-08 00:03 |
|
Hejsa...
Hvordan er det nu lige, at man mest elegant finder forrige / næste i en
alfabetisk sorteret liste (især forrige har jeg problemer med).?
Lad os sige, at vi har en liste som sorteret ser sådan her ud.
Jeg ved nu, at id 915 er Herman Hegelahr. Men hvordan finder jeg nemmest
ud af, at forrige er id 929 og at næste er 913.?
id;efternavn;fornavn;bopæl
908;Engelbredtsen;Edel Frederikke;
907;Engelbredtsen;Engelbredt;
920;Engelbredtsen;Knud;Hads Herred
928;Engelbretsen;Knud;Odder
929;Engelbricht;Knud;Hads Herred
915;Hegelahr;Herman;
913;Hegelahr;Herman;
912;Hegelahr;Herman;Bryskesborg
914;Hegelahr;Herman;Kolding
911;Hegelahr;Herman;Rårup
910;Hegelahr;Herman;Rårup
916;Hegelahr;Herman;Rårup
909;Hegelahr;Herman;Rårup
918;Hegelahr;Johan;Hassing
919;Hegelahr;Johan;Karleby
917;Hegelahr;Johan;Sakskøbing
id (autoincrement) er primary key, der er index på efternavn og fornavn.
Jeg troede så, at jeg kunne finde ud af at bruge "handler" til at læse
direkte i index. Men det kan jeg ikke rigtig få til at lykkes. Og da
slet ikke når mit udgangspunkt er id nummeret.
Og jeg kan jo ikke bare sortere på navnene og så bruge 'mindre end' og
'større end' når der er mange der hedder det samme.
--
mvh, A:\Feldborg
Slægtsforskning og lokalhistorie i midt- vestjylland
http://hammerum-herred.dk/
| |
Arne Vajhøj (21-03-2008)
| Kommentar Fra : Arne Vajhøj |
Dato : 21-03-08 00:47 |
|
Arne Feldborg wrote:
> Hvordan er det nu lige, at man mest elegant finder forrige / næste i en
> alfabetisk sorteret liste (især forrige har jeg problemer med).?
>
> Lad os sige, at vi har en liste som sorteret ser sådan her ud.
>
> Jeg ved nu, at id 915 er Herman Hegelahr. Men hvordan finder jeg nemmest
> ud af, at forrige er id 929 og at næste er 913.?
>
> id;efternavn;fornavn;bopæl
> 908;Engelbredtsen;Edel Frederikke;
> 907;Engelbredtsen;Engelbredt;
> 920;Engelbredtsen;Knud;Hads Herred
> 928;Engelbretsen;Knud;Odder
> 929;Engelbricht;Knud;Hads Herred
> 915;Hegelahr;Herman;
> 913;Hegelahr;Herman;
> 912;Hegelahr;Herman;Bryskesborg
> 914;Hegelahr;Herman;Kolding
> 911;Hegelahr;Herman;Rårup
> 910;Hegelahr;Herman;Rårup
> 916;Hegelahr;Herman;Rårup
> 909;Hegelahr;Herman;Rårup
> 918;Hegelahr;Johan;Hassing
> 919;Hegelahr;Johan;Karleby
> 917;Hegelahr;Johan;Sakskøbing
>
> id (autoincrement) er primary key, der er index på efternavn og fornavn.
SELECT *
FROM tabel
WHERE efternavn > 'Hegelahr' OR (efternavn = 'Hegelahr' AND fornavn >
'Herman')
ORDER BY efternavn,fornavn
LIMIT 1
SELECT *
FROM tabel
WHERE efternavn < 'Hegelahr' OR (efternavn = 'Hegelahr' AND fornavn <
'Herman')
ORDER BY efternavn DESC,fornavn DESC
LIMIT 1
(LIMIT 1 er MySQL syntax - skal rettes for andre databaser)
Arne
| |
Arne Feldborg (21-03-2008)
| Kommentar Fra : Arne Feldborg |
Dato : 21-03-08 07:43 |
|
Arne Vajhøj <arne@vajhoej.dk> skrev Thu, 20 Mar 2008 19:47:08 -0400
>WHERE efternavn > 'Hegelahr' OR (efternavn = 'Hegelahr' AND fornavn >
>'Herman')
<[......]
>WHERE efternavn < 'Hegelahr' OR (efternavn = 'Hegelahr' AND fornavn <
>'Herman')
>ORDER BY efternavn DESC,fornavn DESC
>
Tak for forslaget. Men det vil jo desværre netop ikke virke, når der er
flere personer der hedder det samme.
--
mvh, A:\Feldborg
Slægtsforskning og lokalhistorie i midt- vestjylland
http://hammerum-herred.dk/
| |
Philip Nunnegaard (21-03-2008)
| Kommentar Fra : Philip Nunnegaard |
Dato : 21-03-08 08:08 |
|
"Arne Feldborg" <feldborg@haunstrup.dk> skrev i meddelelsen
news:i3m6u3lj56umk75uvbf5fop8hlqqjb231l@4ax.com...
> Tak for forslaget. Men det vil jo desværre netop ikke virke, når der er
> flere personer der hedder det samme.
Er ikke afprøvet, men hvis det virker, burde den også fange andre, der
hedder Herman Helgelahr, bare de ikke har id=915:
Næste person:
select *
from tabel
where (efternavn > 'Hegelahr' or efternavn = 'Hegelahr') and (fornavn >
'Herman' or fornavn = 'Herman') and id <> 915
order by efternavn,fornavn
limit 1
Forrige person:
select *
from tabel
where (efternavn < 'Hegelahr' or efternavn = 'Hegelahr') and (fornavn <
'Herman' or fornavn = 'Herman') and id <> 915
order by efternavn,fornavn desc
limit 1
| |
Philip Nunnegaard (21-03-2008)
| Kommentar Fra : Philip Nunnegaard |
Dato : 21-03-08 08:17 |
|
"Philip Nunnegaard" <philipnospam@hitsurf.dk> skrev i meddelelsen
news:47e35ee0$0$15880$edfadb0f@dtext01.news.tele.dk...
> Næste person:
> select *
> from tabel
> where (efternavn > 'Hegelahr' or efternavn = 'Hegelahr') and (fornavn >
> 'Herman' or fornavn = 'Herman') and id <> 915
> order by efternavn,fornavn
> limit 1
OK! Den vil ikke fange, hvis næste person f.eks. hedder Anne Jensen.
Det skulle dette til gengæld:
select *
from tabel
where (efternavn > 'Hegelahr' or (efternavn = 'Hegelahr' and (fornavn >
'Herman' or fornavn = 'Herman')) and id <> 915
order by efternavn,fornavn
limit 1
| |
Arne Vajhøj (22-03-2008)
| Kommentar Fra : Arne Vajhøj |
Dato : 22-03-08 01:13 |
|
Arne Feldborg wrote:
> Arne Vajhøj <arne@vajhoej.dk> skrev Thu, 20 Mar 2008 19:47:08 -0400
>> WHERE efternavn > 'Hegelahr' OR (efternavn = 'Hegelahr' AND fornavn >
>> 'Herman')
> <[......]
>> WHERE efternavn < 'Hegelahr' OR (efternavn = 'Hegelahr' AND fornavn <
>> 'Herman')
>> ORDER BY efternavn DESC,fornavn DESC
>>
> Tak for forslaget. Men det vil jo desværre netop ikke virke, når der er
> flere personer der hedder det samme.
For at "næste" er veldefineret er du nødt til at have et sorterings
kriterie der definerer rækkefølgen entydigt.
Har du det kan du også smække passende WHERE betingelser på.
Du kunne f.eks. definere at ved samme navn sorterer du efter id.
Og så er det:
WHERE efternavn > 'Hegelahr' OR (efternavn = 'Hegelahr' AND fornavn >
'Herman') OR
(efternavn = 'Hegelahr' AND fornavn = 'Herman' AND id < 915)
Arne
| |
Arne Feldborg (22-03-2008)
| Kommentar Fra : Arne Feldborg |
Dato : 22-03-08 02:43 |
|
Arne Vajhøj <arne@vajhoej.dk> skrev Fri, 21 Mar 2008 20:13:05 -0400
>WHERE efternavn > 'Hegelahr' OR (efternavn = 'Hegelahr' AND fornavn >
>'Herman') OR
>(efternavn = 'Hegelahr' AND fornavn = 'Herman' AND id < 915)
>
Ja, det er ingen kunst at gå 'fremad'. Problemet er når man skal
tilbage. Jeg tvivler ikke på, at det kan lade sig gøre, men det er nu
ikke helt så ligetil.
Hvis vi har en liste de ser sådan her ud, med id som det tredie og
unikke sorteringsparameter, så vil den 'lige før' nr 917 blive nr 909,
og det var jo ikke meningen.
908 - Engelbredtsen - Edel Frederikke
907 - Engelbredtsen - Engelbredt
920 - Engelbredtsen - Knud
928 - Engelbretsen - Knud
929 - Engelbricht - Knud
909 - Hegelahr - Herman
910 - Hegelahr - Herman
911 - Hegelahr - Herman
912 - Hegelahr - Herman
913 - Hegelahr - Herman
914 - Hegelahr - Herman
915 - Hegelahr - Herman
916 - Hegelahr - Herman
917 - Hegelahr - Johan
918 - Hegelahr - Johan
919 - Hegelahr - Johan
Med det forslag du postede vil man med eet skridt tilbage springe
direkte til nr 929 uanset hvor man står i rækken 916-909.
--
mvh, A:\Feldborg
Slægtsforskning og lokalhistorie i midt- vestjylland
http://hammerum-herred.dk/
| |
Arne Vajhøj (22-03-2008)
| Kommentar Fra : Arne Vajhøj |
Dato : 22-03-08 04:32 |
|
Arne Feldborg wrote:
> Arne Vajhøj <arne@vajhoej.dk> skrev Fri, 21 Mar 2008 20:13:05 -0400
>
>
>> WHERE efternavn > 'Hegelahr' OR (efternavn = 'Hegelahr' AND fornavn >
>> 'Herman') OR
>> (efternavn = 'Hegelahr' AND fornavn = 'Herman' AND id < 915)
>>
> Ja, det er ingen kunst at gå 'fremad'. Problemet er når man skal
> tilbage. Jeg tvivler ikke på, at det kan lade sig gøre, men det er nu
> ikke helt så ligetil.
>
> Hvis vi har en liste de ser sådan her ud, med id som det tredie og
> unikke sorteringsparameter, så vil den 'lige før' nr 917 blive nr 909,
> og det var jo ikke meningen.
>
> 908 - Engelbredtsen - Edel Frederikke
> 907 - Engelbredtsen - Engelbredt
> 920 - Engelbredtsen - Knud
> 928 - Engelbretsen - Knud
> 929 - Engelbricht - Knud
> 909 - Hegelahr - Herman
> 910 - Hegelahr - Herman
> 911 - Hegelahr - Herman
> 912 - Hegelahr - Herman
> 913 - Hegelahr - Herman
> 914 - Hegelahr - Herman
> 915 - Hegelahr - Herman
> 916 - Hegelahr - Herman
> 917 - Hegelahr - Johan
> 918 - Hegelahr - Johan
> 919 - Hegelahr - Johan
>
> Med det forslag du postede vil man med eet skridt tilbage springe
> direkte til nr 929 uanset hvor man står i rækken 916-909.
Øh.
SELECT *
FROM tabel
WHERE efternavn < 'Hegelahr' OR (efternavn = 'Hegelahr' AND fornavn <
'Herman') OR
(efternavn = 'Hegelahr' AND fornavn = 'Herman' AND id < 915)
ORDER BY efternavn DESC,fornavn DESC,id DESC
LIMIT 1
bør da finde nummer 914.
Arne
| |
Arne Feldborg (22-03-2008)
| Kommentar Fra : Arne Feldborg |
Dato : 22-03-08 10:33 |
|
Arne Vajhøj <arne@vajhoej.dk> skrev Fri, 21 Mar 2008 23:32:11 -0400
>> Med det forslag du postede vil man med eet skridt tilbage springe
>> direkte til nr 929 uanset hvor man står i rækken 916-909.
>
>Øh.
>
Problemet der var nok, at præcis de samme betingelser skal indgå både i
WHERE og i ORDER BY klausulerne - hverken mere eller mindre.
Gælder måske især når man arbejder sig nedad.
Med dit senste forslag som udgangspunkt for 'Tilbage', og med "Philips
seneste forslag som udgangspunkt til en 'Fremad', har jeg nu fået det
til at virke efter hensigten.
Mange tak for hjælpen til alle.
--
mvh, A:\Feldborg
Slægtsforskning og lokalhistorie i midt- vestjylland
http://hammerum-herred.dk/
| |
Jørn Andersen (21-03-2008)
| Kommentar Fra : Jørn Andersen |
Dato : 21-03-08 02:43 |
|
On Fri, 21 Mar 2008 00:03:02 +0100, Arne Feldborg
<feldborg@haunstrup.dk> wrote:
>Hvordan er det nu lige, at man mest elegant finder forrige / næste i en
>alfabetisk sorteret liste (især forrige har jeg problemer med).?
Det kommer lidt an på, *hvor* du skal finde forrige/næste.
Hvis formålet med din SQL er at danne et RecordSet, kan du brug
RecordSet'ets .MoveNext- og .MovePrevious-metoder.
Ellers fortæl lidt mere om i hvilken sammenhæng.
Good luck!
--
Jørn Andersen,
Brønshøj
| |
Arne Feldborg (21-03-2008)
| Kommentar Fra : Arne Feldborg |
Dato : 21-03-08 07:57 |
|
Jørn Andersen <jorn@jorna.dk> skrev Fri, 21 Mar 2008 02:42:59 +0100
>Det kommer lidt an på, *hvor* du skal finde forrige/næste.
>Hvis formålet med din SQL er at danne et RecordSet, kan du brug
>RecordSet'ets .MoveNext- og .MovePrevious-metoder.
>
Allerførst undskyld at jeg glemte at nævnew platformen. Det er MySql 5.0
på Apache og Windows.
Probelemt er jo, at RecordSet'et kun indeholder een post. Det jeg har
brug for er derudfra at kunne finde den næste og den foregående.
>Ellers fortæl lidt mere om i hvilken sammenhæng.
>
Det skal såmænd bare bruges til at lave et link til næste / foregående
person.
Det jeg evt. kunne fidne ud af er, at søge på to navne henholdsvis
mindre end og større end det aktuelle - og så hente *alle* poster
derimellem.
Så vil jeg jo ret snildt kunne finde frem til den lige før og den lige
efter det aktuelle.
Men det kommer på sigt til at handle om flere hundredtusinde navne, så
jeg tænkte om der fandtes en mere smart metode, til kun at hente de to
recordset jeg har brug for.
--
mvh, A:\Feldborg
Slægtsforskning og lokalhistorie i midt- vestjylland
http://hammerum-herred.dk/
| |
Peter Lykkegaard (21-03-2008)
| Kommentar Fra : Peter Lykkegaard |
Dato : 21-03-08 10:09 |
|
"Arne Feldborg" skrev
> Probelemt er jo, at RecordSet'et kun indeholder een post. Det jeg har
> brug for er derudfra at kunne finde den næste og den foregående.
>
Dvs et slags paging system hvor du kun henter relevante antal records (i
dette een record) og paging skal foregå på serveren
Jeg har et eksempel på dette hvor det er MSSQL/ASP involveret
Men mon ikke det kan omsættes til de relevante systemer da det meste foregår
serverside?
Paging through Records using a Stored Procedure
http://www.4guysfromrolla.com/webtech/062899-1.shtml
Hmm der er siden kommet denne version
A More Efficient Method for Paging Through Large Result Sets
http://www.4guysfromrolla.com/webtech/042606-1.shtml
- Peter
| |
Jens Gyldenkærne Cla~ (21-03-2008)
| Kommentar Fra : Jens Gyldenkærne Cla~ |
Dato : 21-03-08 11:39 |
|
Arne Feldborg skrev:
> Det skal såmænd bare bruges til at lave et link til næste /
> foregående person.
Det lyder lidt som om du kunne bruge en linked list-struktur - hvor
du i selve tabellen angiver id-værdien på den efterfølgende post i
en given sortering.
Det vil gøre select-forespørgslerne meget simple, men vil til
gengæld betyde ekstra arbejde når der indsættes, opdateres eller
slettes data - så hvorvidt det er praktisk eller ej, vil afhænge af
hvordan databasen benyttes.
--
Jens Gyldenkærne Clausen
»Diplomatiet består netop i, at de gamle kommatister kan få lov til
at tro, at de har vundet. Men i virkeligheden har de tabt.«
Ole Togeby i Information
| |
Arne Feldborg (21-03-2008)
| Kommentar Fra : Arne Feldborg |
Dato : 21-03-08 14:13 |
|
"Jens Gyldenkærne Clausen" <jens@gyros.invalid> skrev Fri, 21 Mar 2008
11:39:15 +0100
>Det lyder lidt som om du kunne bruge en linked list-struktur - hvor
>du i selve tabellen angiver id-værdien på den efterfølgende post i
>en given sortering.
>
Det lyder rimeligt nok. Og jeg vil ikke afvise, at jeg i lige netop den
her situation godt kan acceptere en lidt tungere vedligeholdelse, hvis
det til gengæld giver en mere smidig afvikling af forespørgsler.
Men det ligger nok lidt ud over hvad min viden om emnet rækker til.
Kunne du evt henvise til et eksempel eller noget læsestof.?
--
mvh, A:\Feldborg
Slægtsforskning og lokalhistorie i midt- vestjylland
http://hammerum-herred.dk/
| |
Arne Feldborg (21-03-2008)
| Kommentar Fra : Arne Feldborg |
Dato : 21-03-08 14:05 |
|
Arne Feldborg <feldborg@haunstrup.dk> skrev Fri, 21 Mar 2008 00:03:02
+0100
>Hvordan er det nu lige, at man mest elegant finder forrige / næste i en
>alfabetisk sorteret liste (især forrige har jeg problemer med).?
>
Tak for alle svarene, nu er der noget at arbejde videre med.
Mene, men, men.....
Det er gået op for mig, at en del af problemet måske er at sorteringen i
visse tilfælde opfører sig anderledes end jeg forventer. Jeg ville sætte
meget stor pris på, om i mere erfarne vil kommentere det her
Hvis jeg laver denne forespørgsel får jeg et antal svar.
SELECT * from nygaard.dat_pics
where e_navn != ''
and e_navn >= 'Engelbricht'
and e_navn <= 'Hegelahr'
order by e_navn, f_navn
929;Engelbricht;Knud;Hads Herred
910;Hegelahr;Herman;Rårup
911;Hegelahr;Herman;Rårup
912;Hegelahr;Herman;Bryskesborg
913;Hegelahr;Herman;
914;Hegelahr;Herman;Kolding
915;Hegelahr;Herman;
916;Hegelahr;Herman;Rårup
909;Hegelahr;Herman;Rårup
917;Hegelahr;Johan;Sakskøbing
918;Hegelahr;Johan;Hassing
919;Hegelahr;Johan;Karleby
Hvis jeg nu i stedet laver den her forespørgsel:
SELECT * from nygaard.dat_pics
where e_navn != ''
and e_navn = 'Hegelahr'
and f_navn = 'Herman'
order by e_navn, f_navn
916;Hegelahr;Herman;Rårup
915;Hegelahr;Herman;
914;Hegelahr;Herman;Kolding
913;Hegelahr;Herman;
912;Hegelahr;Herman;Bryskesborg
911;Hegelahr;Herman;Rårup
910;Hegelahr;Herman;Rårup
909;Hegelahr;Herman;Rårup
Så får jeg naturligvis færre svar. Men hvorfor i alverden rækkefølgen
anderledes, og ikke nok med det. Også den indbyrdes rækkefølge er
anderledes.
Det er jo præcis samme 'order by' klausul??
Jeg kan jo nok regne ud, at med 8 enslydende navne må Sql ty til andre
hjælpemidler for at genemføre sorteringen. Men jeg havde dog forventet,
at selve den indbyrdes rækkefølge af de 8 enslydende navne ville være
ens i de to situationer.
--
mvh, A:\Feldborg
Slægtsforskning og lokalhistorie i midt- vestjylland
http://hammerum-herred.dk/
| |
Leif Neland (21-03-2008)
| Kommentar Fra : Leif Neland |
Dato : 21-03-08 19:29 |
|
Arne Feldborg skrev:
> Arne Feldborg <feldborg@haunstrup.dk> skrev Fri, 21 Mar 2008 00:03:02
> +0100
>
>
>
> Det er gået op for mig, at en del af problemet måske er at sorteringen i
> visse tilfælde opfører sig anderledes end jeg forventer. Jeg ville sætte
> meget stor pris på, om i mere erfarne vil kommentere det her
>
> SELECT * from nygaard.dat_pics
> where e_navn != ''
> and e_navn >= 'Engelbricht'
> and e_navn <= 'Hegelahr'
> order by e_navn, f_navn
>
>
> Hvis jeg nu i stedet laver den her forespørgsel:
>
> SELECT * from nygaard.dat_pics
> where e_navn != ''
> and e_navn = 'Hegelahr'
> and f_navn = 'Herman'
> order by e_navn, f_navn
>
> Så får jeg naturligvis færre svar. Men hvorfor i alverden rækkefølgen
> anderledes, og ikke nok med det. Også den indbyrdes rækkefølge er
> anderledes.
>
> Det er jo præcis samme 'order by' klausul??
>
> Jeg kan jo nok regne ud, at med 8 enslydende navne må Sql ty til andre
> hjælpemidler for at genemføre sorteringen. Men jeg havde dog forventet,
> at selve den indbyrdes rækkefølge af de 8 enslydende navne ville være
> ens i de to situationer.
>
Muligvis forventeligt, men ikke garanteret.
Når der ikke er andre kriterier, så må du angive nok kriterier til at
din rækkefølge er defineret tilstrækkeligt.
F.ex. e_navn,f_navn,bynavn,id eller e_navn,f_navn,id
Leif
| |
Martin (23-03-2008)
| Kommentar Fra : Martin |
Dato : 23-03-08 15:33 |
|
Arne Feldborg wrote:
> Hejsa...
>
> Hvordan er det nu lige, at man mest elegant finder forrige / næste i en
> alfabetisk sorteret liste (især forrige har jeg problemer med).?
>
> Lad os sige, at vi har en liste som sorteret ser sådan her ud.
>
> Jeg ved nu, at id 915 er Herman Hegelahr. Men hvordan finder jeg nemmest
> ud af, at forrige er id 929 og at næste er 913.?
>
> id;efternavn;fornavn;bopæl
> 908;Engelbredtsen;Edel Frederikke;
> 907;Engelbredtsen;Engelbredt;
> 920;Engelbredtsen;Knud;Hads Herred
> 928;Engelbretsen;Knud;Odder
> 929;Engelbricht;Knud;Hads Herred
> 915;Hegelahr;Herman;
> 913;Hegelahr;Herman;
> 912;Hegelahr;Herman;Bryskesborg
> 914;Hegelahr;Herman;Kolding
> 911;Hegelahr;Herman;Rårup
> 910;Hegelahr;Herman;Rårup
> 916;Hegelahr;Herman;Rårup
> 909;Hegelahr;Herman;Rårup
> 918;Hegelahr;Johan;Hassing
> 919;Hegelahr;Johan;Karleby
> 917;Hegelahr;Johan;Sakskøbing
>
> id (autoincrement) er primary key, der er index på efternavn og fornavn.
>
> Jeg troede så, at jeg kunne finde ud af at bruge "handler" til at læse
> direkte i index. Men det kan jeg ikke rigtig få til at lykkes. Og da
> slet ikke når mit udgangspunkt er id nummeret.
>
> Og jeg kan jo ikke bare sortere på navnene og så bruge 'mindre end' og
> 'større end' når der er mange der hedder det samme.
>
Jeg tror du griber det helt forkert an...
Jeg gætter på du vil lave Forrige og Næste links, her bruger man ikke
ID, men limit.
Første side hedder så noget ala
index.php?page=0
Så hedder næste link så page=1
SQL strengen til følgende hedder så
SELECT
...
FROM
...
WHERE
...
ORDER BY
...
LIMIT $_GET['page'],1
For at hente total antal sider
SELECT COUNT(*) as total FROM table
| |
Arne Feldborg (23-03-2008)
| Kommentar Fra : Arne Feldborg |
Dato : 23-03-08 22:30 |
|
Martin <martin@aarhof.invalid> skrev Sun, 23 Mar 2008 15:33:23 +0100
>Jeg tror du griber det helt forkert an...
>Jeg gætter på du vil lave Forrige og Næste links, her bruger man ikke
>ID, men limit.
>
Det er jeg udmærket klar over. Men id på det valgte person er nu engang
min indgang til tabellen. Og derfor er det udgangspunktet for det videre
forløb.
Og id er er også det eneste man kan være 100% sikker på der er unikt,
derfor må det også indgå som en del (men natuligvis kun som en del) af
sorteringen.
Jeg kan jo ikke bare løbe hele tabellen igennem fra a til z for hvert
opslag. Hvis jeg kunne det, så var der jo ingen problemer, så var det jo
bare at bladre frem og tilbage i et array.
Tak for dit forslag, det indgår i overvejlserne.
--
mvh, A:\Feldborg
Slægtsforskning og lokalhistorie i midt- vestjylland
http://hammerum-herred.dk/
| |
|
|