Prepared statement - Tjek

<ole>


/mvh
</bole>

mysqli_stmt::$affected_rows

Fedt! Findes der så også en funktion som sammenligner en foreach med databasens indhold?

Det må være noget med:

DELETE FROM `ad_hoc` WHERE NOT `id` = ?

Forstår du mon selv, hvad du skriver?  =)

Egentlig ikke :(

Hvordan kommer vi så videre fra #2?  =)

Sagen er den at jeg via noget XML DOM med foreach henter noget data fra en HTML tabel fra en anden side. I første omgang tilføjer jeg alle disse rækker til databasen (koden i post #0 + #1)

Nu er problemet så bare at der i databasen skal slettes de rækker som ikke længere eksisterer i HTML tabellen.

Okay, én ting ad gangen: En af fordelene ved at bruge prepared statements er, at det oprettede statement 'compiles' af databasen. Derefter kan det samme statement eksekveres så mange gange, det måtte ønskes - med nye værdier for hver eksekvering.

Jeg har lidt på fornemmelsen, du opretter og lukker dit statement inde i en løkke. Prøv denne fremgangsmåde i stedet:


Jeg kender ikke din løkkekode, så jeg har bare angivet loopet med pseudokode.

Hvis der er tale om 10-20-50-100 rækker, så slet alle rækker og indsæt dem på ny. Med prepared statements går det lynhurtigt

@Stefan1: Når vi tale MySQLI, er det meget ofte i forbindelse med sikkerhed. Der er er dog en anden meget væsentlig begrundelse for at bruge prepared statements, og der er #9 et skoleeksempel.

Når du kalder MySQLI-klassens prepare metode, parser denne den streng, du sender med. Du kan derefter opfatte det som, at databasen opretter en funktion, der udfører det, strengen siger, når funktionen senere bliver kaldt.

Med det returnerede statements bind_param og execute metoder kalder du funktionen. Det er bare et kald, som er opdet i to faser: Først angives argumenterne (parametrene) og derefter kaldes (eksekveres) funktionen.

Det fungerer lidt på samme måde, som når du i PHP skriver en funktion og kalder den mange gange med forskellige argumenter.

I det gamle MySQL-API skulle databasen 'bygge hele maskinen' hvergang et kald blev udført.

Intet er dog helt gratis, og MySQLI er faktisk marginalt langsommere på enkeltkald - men altså dramtisk hurtigere på repeterende kald.

Du bør altså som hovedregel oprette et statement og vente med at lukke det, til du ikke længere har brug for det indenfor samme funktion. Du kan sagtens oprette flere - blot giv dem forskellige navne. Ligesom du ville gøre det med almindelige funktioner/objekter

@olebole: Du havde ret i at jeg oprettede og lukkede mit statement inde i en løkke. Jeg har nu rettet det i forhold til #9 - Rigtig god forklaring - Jeg lærte helt sikkert noget nyt :o

Forstod du hvad det var jeg mente i #8?

Det tror jeg - og i så fald var svaret: "Hvis der er tale om 10-20-50-100 rækker, så slet alle rækker og indsæt dem på ny. Med prepared statements går det lynhurtigt"  =)

Er der tale om forholdsvis få rækker, kan det hurtigt blive mindre effektivt at prøve at slette enkeltrækker

#13 Jeg vil helst gøre det sådan at den kun udskriver de nye som er kommet til.
Via koden:



Hvis jeg sletter alle rækker så vil den indsætte rækker som allerede har været i databasen før sletningen. Hvis jeg nu sendte en mail ud via php hver gang der blev indsat en ny række ville man få tilsendt en mail med med de samme rækker da den bare indsætter de samme i databasen.

Okay, nu forstår jeg. Jeg havde vist misforstået projektet lidt fra start  =)

Jeg ville gå en anden vej. Jeg ville kun indsætte de rækker, der ikke allerede er i databasen - og derefter sende mails ud om dem, der blev indsat.

Det kræver, der i hver række står noget i et af dine XML-items, som er unikt for lige netop dén række. Så vil man nemlig kunne udnytte, at MySQL kaster en fejl 1062, hvis man har et unikt felt i databasen - og man prøver at indsætte noget, der står i forvejen.

Da jeg ikke kender dine data, får du her en mere generisk løsning: Opret et ekstra felt i databasen. Det skal være af typen VARCHAR - have en max-længde på 32 - og sættes til at være unik.

Så kan du prøve med følgende kode:


Jeg danner en md5-hash af alle felternes samlede indhold og forsøger at sætte den ind sammen med de andre data. Hvis denne hash findes i forvejen, vil execute smide en fejl. Den undertrykker vi dog med et @ foran kaldet.

Opstår der en fejl 1062, gør vi intet. Gør der ikke det, tjekker vi for andre fejl. Opstod der ikke andre fejl, hælder vi data ned i array'et $arrInfo4Mails - som til sidst kan bruges til mail-udsendeing.

Ved koden:


- kan du selv afgøre, hvilke data du vil have med - og efterfølgende rette linjen, hvor de fyldes i array'et.

Det burde virke  =)

PS: Med min kode skal det nye felt hedde hash

Tak. Kigger på det.

Gør det ... og spørg endelig  =)

Jeg indsætter allerede de rækker som ikke findes i databasen.
Da Jeg har et unikt nummer i form af id (ikke auto increment) bliver dem som allerede findes i databasen ikke tilføjet igen. Det som er problemet er at hvis de data som skal indsættes i databasen ikke findes mere i dom objektet skal det fjernes fra databasen. Indholdet fra Dom dokumentet skal simpelthen være identisk med databasen.

Okay, så havde jeg faktisk forstået det korrekt i første omgang!  :D

Så er vi tilbage i at slette alle rækker først - og derefter indsætte DOM-objektets rækker:


- og derefter kører du koden i #9.

Det kræver flere resourcer at sammenligne DOM-objektet og databasen for at slette rækker, der ikke spejler DOM'en. Når du opretter et prepared statement og genbruger det til flere/mange indsættelser, går det rasende hurtigt. Du kan slet ikke sammenligne det med det gamle API ved gentagne kald

Jeg tror stadig ikke at jeg helt har forklaret mig korrekt.
Jeg kan godt se idéen med at slette alle rækker og derefter indsætte dem via DOM-objektet - Så er det opdateret - det er rigtigt.

Men Problemet er jo så bare at jeg via mail sender en mail pr række som er indsat.
Det vil den så gøre for hver gang at den har kørt DELETE FROM forespørgslen.

En rækkes indsættelse må kun sendes én gang via mail. Så hvis den slette via DELETE FROM og derefter indsættes igen fordi at den stadig findes i DOM-objektet så vil den jo sende mail en gang til fordi at den er indsat og det må den ikke.

Så forstår jeg ... igen!  :D

Mon ikke, det er sådan noget lignende, du så efterspørger?

Det forudsætter, jeg har gættet rigtigt, og dit id ligger i item(0)  =)

Dohhhh ... det står der jo i SQL'en, Ole!

Hehe Ole.

Efter at jeg har sat det sammen får jeg: unexpected T_STRING

|

Kan det have noget at gøre med at id'et i DOM'en går fra ca 34079?

Nej, det burde ikke betyde noget. Gad vide, hvad der står i det felt, hvor den fejler? Prøv lige:

Sorry havde glemt at tilføje indholdet til din $res variabel :s

Nu viser den alt indhold nederst i et array men jeg får også denne fejl øverst:
Undefined index: 34453  on line 73  <---- 34453 er id'et for rækken

Dette viser den hele vejen ned på siden med hvert unikt id.


Her er linie 73:

Årrhhh ... det er mig, der er en torsk! Skift den linje ud med:


- sorry  =)

Ole. Du er genial :D

Tusind tak.

Selvtak. Gammel, bad practice slår desværre af og til igennem hos ældre mænd, når de ikke tester deres kode. Det er sgu'tte så genialt  :D

Du lægger som vanligt selv et svar og accepterer, så tråden lukkes  =)

Svar.

Er det muligt at lave en foreach med arrayet: $arrData4mails i bunden?

Ja, det kan du altid med et array:

Ved hjælp af dit eksempel får jeg det udkrevet således:


Men jeg kunne også godt bruge selve værdierne som befinder sig selve array'et


Har prøvet med følgende kode taget inde fra php.net manualen der for jeg udskrevet værdien af første variabel men i den næste for jeg blot 1 og 0 taller.



Hvordan er det lige jeg får $key som $cols->item(0)->nodeValue
samt $value som $cols->item(1)->nodeValue ?

Når. Sådan her :)

Tak.

foreach ($arrData4mails as $key) {
    echo $key[0] . ' => ' . $key[1] . '<br>';
}