Bármilyen kommunikáció bármikor megszakadhat. Ha például az ESP már elküldte a legutóbbi adatsort, de az valamiért nem érkezik meg a szerverre, akkor nem kerül be az adatbázisba az a néhány érték. Ennek a valószínűsége még WIFI-n is kicsi, ezért várhatóan csak nagyon ritkán fogsz ilyennel találkozni, és akkor vakarhatod a fejedet...
Bármilyen csatornát is használsz, elvileg lehetetlen biztosan ugyanazt tudni mindkét oldalon. Az SQL szerver adhat nyugtát, hogy ő már mentette is az adatokat, akkor törölheti a régi adatokat az ESP. (De ekkor meg az SQL nem tudhatja biztosan, hogy ez a törlés valóban megtörtént! Ha az SQL elküldte a törlést kívánó nyugtát, de az ESP nem kapta meg valami okból, akkor egy bejegyzés kétszer került az adatbázisba!) (A TCP stream alapú, nem üzenet alapú, de a probléma alaptermészete ugyanaz marad a felépítményektől függetlenül: az utolsó nyugtában sosem lehetünk biztosak, hogy a másik oldal megkapta, és így nem tudhatjuk, hogy megtörtént-e a régi értékek törlése, vagy az új események loggolása.)
A probléma megoldása az, hogy olyan üzeneteket kell kitalálni, amiknek az esetleges ismétlése nem okoz galibát, és az aktív oldal (esetedben a szerver) valóban ismétel, ha valami nem sikerült. Például itt a szerver elküldheti az utolsó loggolt esemény sorszámát, vagy időbélyegét. És akkor az ESP tudja, hogy addig kell törölni és az újabbakat elküldeni. (A nyugta és az új adatok lekérése egy üzenetbe van összevonva: ez egy régi jól bevált trükk.) Ez a protokoll, ha belegondolsz garantálja, hogy átmegy minden azonosító akkor is, ha közben akárhány kapcsolat is lehal. (Feltéve, hogy az ESP puffer betelés előtt azért történik legalább egy hibátlan kapcsolatfelvétel is nyilván.)
Egy másik beleköthető pont, hogy inputot nem szokás SQL-be direkben bevágni, mert SQL injectiont lehet csinálni vele. Bár tény, hogy ez a leggyorsabban lefutó megoldás, és nyilván a szenzor helyén nem kellene támadónak lenni, de mégsem szokás.