Undgå dobbeltposter i tabel!

du ku "select gst_name from tabelnavn where gst_name='$name' and gst_email='$email' and osv"

if numrows af denne select == 0
    insert

if ($send) {
   
    $tjek = mysql_query("SELECT id FROM tabelnavn WHERE gst_name = '$gst_name' AND gst_email = '$gst_email'AND  gst_country = '$gst_country' AND gst_homepage ='$gst_homepage' AND gst_message='$gst_message'");
   
    if (mysql_num_rows($tjek) == "1") {
        echo "fejl";
} else {
INSERT INTO tabelnavn (gst_name, gst_email, gst_country, gst_homepage, gst_message) values('$name', '$email', '$country', '$homepage', '$message');
}

hmmm lidt for langsom.

Ok - det fungerer hvertfald - er det ikke muligt at lave vha. replace? - det synes jeg beskrivelsen i manualen tyder på...

lav filtreringen når du henter data ud fra DB'en, ved hjælp af distinct.

Select distinct(gst_message), gst_name, ..... resten af data from tabelnavn

disky: Jeg kan bedre lide kun at indsætte dataene i db'en hvis det er nødvendigt - det med at filtrere udtrækket er lidt en høkerløsning synes jeg!

Er det ikke fordi brugerne trykker flere gange på submit-knappen? I så fald har jeg et lille JavaScript, som får submit-knappen til at forsvinde og istedet skrive eks. "vent venligst mens der skrives i gæstebogen"...

Jeg har selv løst problemet på den måde :o)

/Muddi

hvad med at bruge update så opdater data hvor data = indtastet med data

du kunne også lave en reload når folk har sendt data således at formen er tom - det er jo vanskeligt at indtaste helt det samme to gange

mortenfn >> Du kan vidst ikke bruge dit sidste forslag i den her situation. Det kunne jeg ihvertfald ikke :o)

Jeg kan ikke lige se hvad der skulle være galt med den metode som Fri-hash og jeg foreslog.

der er da intet galt, men først en select og så en insert intet galt - man kunne også delete og så indsætte - de er begge to funktioner - update er da kun en - men som sagt den anden er lige så god, måske langsommere.

Du kan jo ikke update en row i tabellen som ikke er der. Den vi lavede tjekker om den allerede findes i tabel og vis den ikke gør oprettes den, og vis den gør så får brugeren en fejl melding.

Det er jo korekt - jeg bøjer mig i støvet

Hvorfor er der dog ingen, som foreslår "tipsen" at lave et unikt index på hans tabel ???

Skal kun gøres een gang (evt. ved oprettelse af tabellen) og styrer netop udenom hans problem... det vil sige at det er MySQL som styrer og ikke al mulig kodning...

ALTER TABLE tabelNavn ADD UNIQUE indexNavn (gst_name, gst_email, gst_country, gst_homepage, gst_message);

Jeg ved godt at indexfilen vil tage plads op! - Men det er da den rigtige "database"-måde at gøre tingene på...

"Udover disse felter har jeg et unikt id, samt et timestamp i tabellen - derfor vil poster der er identiske på ovenstående felter stadig være forskellige på disse to felter!"

>fri-hash: Man kan sagtens have FLERE unikke index'er i en tabel... og dette er netop idéen med indexfiler.

Det skal jo være muligt at sige:  (alt sammen vedr. samme tabel)
1) Jeg vil give mine kunder et unikt kundenummer (Unik nøgle-værdi)
2) Jeg vil kun have kunder med unikt telefonnummer (Unikt index på 1 felt)
3) Jeg vil max have 1 kunde pr. gade i hver by. (Unikt index på flere felter)

Dette "lægges ind" i MySQL, så man ikke selv skal kode sig uden om ovenstående forhindringer, men at databasemotoren tager sig af det...

Nu er jeg ved at blive hægtet lidt af svarene, men lige så der ikke er nogen tvivl om udseendet af min tabel:

CREATE TABLE tabelnavn (
  gst_id tinyint(3) unsigned zerofill DEFAULT '000' NOT NULL auto_increment,
  gst_name varchar(50),
  gst_email varchar(50),
  gst_country varchar(50),
  gst_homepage varchar(80),
  gst_message text,
  gst_time timestamp(14),
  PRIMARY KEY (gst_id),
  KEY id (gst_id),
  UNIQUE id2 (gst_id)
);

NB: Mht. de sidste 3 options, er jeg ikke 100% klar over hvad de gør, så det kan godt være lidt tåbeligt - så skal i være velkomne til at fortælle det!

Til alle: Når man har submittet formen, bliver den ikke vist på det efterfølgende billede - dvs. man kan kun submitte den igen, ved at vælge Refresh/Opdater i browseren! Hvis der stadig er tvivl, kan gæstebogen ses på www.tommyipsen.dk !

snigermunken/frihash: Den metode i foreslog fungerer fint, men indebærer 2 forespørgsler, hvilket jeg gerne vil undgå, da jeg ikke tror det er nødvendigt!

proaccess: Det lyder som om det måske er en god idé med et unikt indeks over flere felter, men som min tidligere kommentar nok kraftigt antyder har jeg ikke maks styr på dette - kan du uddybe lidt, hvad du havde forestillet dig, og/eller evt. give et par links, hvor jeg kan læse mere om det? (Udover mysql.com ;-))

NB: Jeg sætter lige pointtallet lidt op, da der er mange som har brugt en del tid på dette!

proaccess: Hvis du gad uddybe din idé vil jeg være glad - jeg ved ikke hvordan man laver et uniks indeks over flere felter!

Som jeg skrev, kunne det være en metode til at få løst dit problem. Ved een gang for alle at tilføje indexet, vil MySQL selv komme med en fejl, hvis man "bryder" reglen (om unike værdier i indexet)

ALTER TABLE tabelnavn ADD UNIQUE indexNavn (gst_name, gst_email, gst_country, gst_homepage, gst_message);

Det vil sige, at når du senere indsætter data i tabellen, vil der blive checkket i index (sker automatisk) og hvis de indexerede data allerede findes, vil MySQL melde fejl.

proaccess - hvis jeg forsøger at lave det index, får jeg en meddelelse om, at kolonnerne ikke må være definerede som "NOT NULL", hvilket er tilfældet på nuværende tidspunkt!

Hvad er det præcist NULL/NOT NULL gør i kolonnetypen?

Jeg har nu rettet fra NULL til NOT NULL (vil stadig gerne vide, hvad forskellien præcist er!) og får nu at vide, at der er et problem med kolonnen gst_message der er af typen text (blob?) og derfor ikke kan bruges i et unik indeks for denne tabeltype....

-what to do...

NULL / NOT NULL  -  Angiver om du må bruge NULL, som dataværdi i dit felt...  NULL er ingenting, "" er en tom string, og der er således forskel på disse...

Med hensyn til gst_message, så må du ændre felt-typen, hvis dette er muligt...

proaccess: Problemet med gst_message er, at det felt indeholder den besked som bliver tastet ind i gæstebogen - jeg kan ikke se, at der er andre felttyper, som er velegnede til at holde disse data?

Var det evt. en (god) idé at ændre tabeltypen - da fejlbeskeden indikerer, at det så måske kan lade sig gøre med indekset!

Og kan man gøre det uden at fjerne indholdet...

Jeg har lige kigget i hjælpen, og den angiver at der skal angives (var det dobbelt-konfekt?) en text-længde på blob (og text) felter...

ALTER TABLE tabelnavn ADD UNIQUE indexNavn (gst_name, gst_email, gst_country, gst_homepage, gst_message(100));

Så laves der index på de første 100 karakterer af gst_message... Håber jeg ;-)

DU SKAL BRUGE VERSION 3.23.2 ELLER NYERE FOR AT DETTE VIRKER !!!

proaccess: Du har helt ret - jeg kan desuden se, at tabeltypen skal være MyISAM for at det kan fungere! - Prøver lige!

Hmm - har godt nok prøvet mange ting nu...

Jeg er gået tilbage til basis og ser om jeg kan oprette en ny tabel med de ønskede specifikationer - jeg har prøvet nedenstående version efter en times konsultation med mysql-manualen:

CREATE TABLE guests4 (
  gst_id tinyint(3) unsigned zerofill DEFAULT '000' NOT NULL auto_increment,
  gst_name varchar(50) NOT NULL,
  gst_email varchar(50) NOT NULL,
  gst_country varchar(50) NOT NULL,
  gst_homepage varchar(80) NOT NULL,
  gst_message text NOT NULL,
  gst_time timestamp(14),
  PRIMARY KEY (gst_id),
  UNIQUE INDEX dblpost (gst_name, gst_email, gst_country, gst_homepage, gst_message(100))
) TYPE=MYISAM;

Problemet er bare, at den giver følgende fejlemeddelelse:

"ERROR 1073: BLOB column 'gst_message' can't be used in key specification with the used table type"

Jeg har nu testet på min lokale mysql, hvor det fungerer fint - men på freepaq's server giver den fejl! Hvis jeg forsøger med phpinfo() på deres site, fortæller den mig ellers, at mysql er version 3.23.49 - burde det så ikke fungere? (Min egen er 3.23.32!)

...jeg fatter det ikke...

Som du selv siger, så funker det nu på din egen maskine, hvorfor det ikke gør det hos freepaq, kan jeg heller ikke lige gennemskue... ;-(

...gad vide om det kan være en bug i den version af mysql...

Det er irriterende... - det er ellers en elegant løsning!

Men jeg har lært meget nyt og brugbart, så jeg takker dig mange gange for hjælpen!

Det var da så lidt... Håber du kommer videre...