Paraméterezett esetben a fejlesztői nyelv általában segítséget nyújt abban, hogy az értéket ne string formában, hanem a nyelv natív adatformátumában (pl. java, .net) adja át, amit az adatbáziskezelő csomag képes olyan formában átadni a db szerver számára, hogy az ne okozzon értelmezési/konverziós problémát.
Persze olyan környezetben, ahol nincs natív datetime formátum, ott ez nem segít...

JOGI NYILATKOZAT: A bejegyzéseim és hozzászólásaim a személyes véleményemet tükrözik; ezek nem tekinthetők a munkáltatóm hivatalos állásfoglalásának...

Szerintem az egész dátum paraméter átadási problémát elkerülhetnéd, ha datetime adattípus átadása helyett stringet adnál át, és használnál dátum konverziós SQL függvényeket .

=Kilroy was here============================ooO=*(_)*=Ooo=======

Idézem, amit itt írt:
"egy 10/11/12-ről megmondani, hogy mi volt az eredeti dátum 33%-os eséllyel lehet - és az adatbáziskezelő is ilyen eséllyel vesz fel jó értéket."
Ez egy jogos szempont, erre hogy alkalmazol dátumkonverziós függvényeket úgy, hogy biztosan a jó eredményt kapd?
Még akkor sem egyértelmű, ha legalább az évszám négy számjegyű, mert így is felcserélődhet a nap-hónap.

====

(#1301) sztanozs : ez végül is igaz.
Mondjuk a UNIX timestamp (másodpercek) legalább tuti nem téved, aztán abból akármilyen formátumra is átalakíthatod.
A felhasználói inputnál meg normális esetben a normális fejlesztő úgyis megoldja, hogy a dátum szigorúbb feltételekhez legyen kötve, akár szétbontva a dátumot külön-külön mezőkre (év, hónap, nap, stb.), akár egy JavaScript-alapú datepickerrel egyszerűbbé téve a választást.

Sk8erPeter

Az a programozó, aki megengedi, hogy bármit beírhassanak a dátum típusú mezőbe, az megérdemli, hogy a tökén végigrobogjon egy GNU csorda. (de látom Te is pont ezt írod alant)

Azt pedig már tényleg csak nagyon zárójelben jegyzem meg, hogy ha a dátum adatok vegyes szerkezetűek, akkor elég nagy felelőtlenség/hanyagság előfeldolgozás nélkül belehányni őket egy dátum típusú mezőbe.

De az eredeti kérdés egyébként így nézett ki:
INSERT INTO log (DateTime, TypeID) VALUES ({ ts '1990-12-31 00:00:00' } , 1)

Szerintem nincs olyan valós indok, ami felhozható a prepare statment ellen. (de szerintem ebben is egyetértünk)

=Kilroy was here============================ooO=*(_)*=Ooo=======

Na várj, szerintem elbeszélünk egymás mellett.
Senki nem is mondta eddig, hogy a prepared statement ne lenne jó, sőt, eddig mindenki amellett érvelt. Amit sztanozs felhozott, az az, hogy adatbázisonként eltérhet a datetime formátuma (erre én is linkeltem a MySQL-es, meg az MSSQL-es példát, hogy máshogy néz ki), ez már eleve problémát okozhat, tehát hiába adsz át stringként prepared statementtel valamit, ha a formátum akkor is rossz, mert mondjuk más formátumra van konfigurálva az adatbázisszerver, vagy mittudomén.
De már kezdek én is belezavarodni.

"Az a programozó, aki megengedi, hogy bármit beírhassanak a dátum típusú mezőbe, az megérdemli, hogy a tökén végigrobogjon egy GNU csorda."

Agreed.

Sk8erPeter

Újabb gyönyörűség. Van egy táblám, benne adatok. Nincs semmilyen kulcs, csak behányva mindenféle adat. Van benne 2 sor, ami totálisan megegyezik, minden mező értéke ugyan az. Ebből kellene SQL lekérdezéssel törölni csak az egyiket. Ezt meg lehet egyáltalán csinálni?

"Mindent azért kell tudni mert kérdezik, nem azért mert hasznos."

Már miért ne lehetne? Összesen van 2 sor, ami egyezik, és az egyik sort törölni szeretnéd? Mi ebben a nehéz? Milyen adatbázis? Milyen adatbázis-kezelőt használsz egyáltalán, hogy a kérdés felmerült?

Sk8erPeter

Hát, az a nehéz benne, hogy nem tudom hogyan kell.

Van egy adatbázis - Access - amiben van rengeteg adat, ebből kikeresem a szar sorokat, és ezekből kellene törölni úgy, hogy csak egy maradjon. ODBC-n fut, és Delphiben kellene rá egy Query-t csinálni, amihez ugye kellene egy SQL parancs. Ez hibádzik.

De örülök, hogy ilyen egyszerű probléma, mert akkor várom a megoldást.

[ Szerkesztve ]

"Mindent azért kell tudni mert kérdezik, nem azért mert hasznos."

Szerencsére nem sok dolgom van Access-szel.
De gyorsan rákeresve ezzel pl. lehet böngészni Access adatbázist is: RazorSQL
Lehet, hogy elbeszélünk egymás mellett, de amit írtál, azt úgy értelmezhető, hogy összesen 2 egyező sor van, és az egyiket törölni kellene. De javíts ki, ha arra gondolsz, hogy MINDEN sorból dupla van......
Ha viszont csak egy, akkor igazából nem vágom, hogy most mi is a probléma, egy rendes grafikus alapú adatbázis-kezelőben csak az adott sornál rámész, hogy delete, és meg is vagy. Vagy beadod query-ként, most csak legegyszerűbb példával élve:
DELETE FROM akármitábla WHERE id = 3
[link]

Sk8erPeter

Próbáld meg az Access grafikus tábla megjelenítőjében jobb gomb, törlés-sel. Persze lehet, hogy ekkor is törli mindkét sort? Bár nem hinném.

Én kérek elnézést!

Egy Delphiben írt program egyik modulja lenne az, hogy bizonyos hiba miatt néha rekordok duplázódnak. Ezekből nem tudjuk mennyi van, vagy hogy hol vannak az adatbázisban. Eljutottam oda, hogy ezek a hibás adatok ki vannak listázva egy DBGrid-be. Itt a user kiválasztja, hogy melyiket hagyjuk meg - sajna így kell csinálni, mivel lehet más hiba is, és oda kell az, hogy el lehessen dönteni melyik maradjon - és a kiválasztottat törölni. Rengeteg sor van, több százezer, és lehet csak egy duplázott sor van benne.
Szóval külön adatbázis böngészőt nem használhatok, nem tudok simán rámenni és törölni. Plusz nincs ilyen, hogy id, nincs semmi. Ilyesmi sorokat képzelj el:
Név | Kártyaszám | Születési hely
Kis Pista | 1 | Budapest
Kis Pista | 1 | Budapest
Nagy Béla | 2 | Debrecen

Ebből kellene az egyik Kis Pistát törölni.

"Mindent azért kell tudni mert kérdezik, nem azért mert hasznos."

Ha csak egy sor van, ami kétszer van benne, akkor kitörlöd mindkettőt, aztán létrehozol egy új sort ugyanazokkal az adatokkal, csak egyszer. Ha sok duplázást kell kiszűrni, akkor meg új tábla kell, nem tudom, hogy az Access támogatja-e a SELECT INTO utasítást, ha igen, akkor így át tudod tölteni az adatokat duplázás nélkül egy új táblába:

select distinct * into UJ_TABLA from REGI_TABLA

Aztán ha megvan, akkor a régi tábla törölhető, az új táblát meg átnevezed a régi nevére. Ha nem megy SELECT INTO, akkor létrehozol egy új táblát a régi mintájára ugyanazzal a mezőkkel, és nyomsz egy ilyet:

insert UJ_TABLA select distinct * from REGI_TABLA

Aztán megint mehet az átnevezés.

Rockbandám: https://fb.me/scharlotterhodes *** Gitárelektronikai műhelyem: https://www.fb.me/goosetgitar

duplikált (vagy akár annál többször ismétlődő) sorok törlése (egy megtartása) a'la Oracle:

DELETE FROM tabla1
WHERE rowid NOT IN
(SELECT MIN(rowid) FROM tabla1
GROUP BY oszlop1, oszlop2, oszlop3, ... );

na most az Access-hez semmi közöm nincs, szóval Google
ha ott is van rowid "metaoszlop", akkor nyert ügy
ha nincs akkor mondjuk legegyszerűbb egy SELECT DISTINCT amit már írtak

[ Szerkesztve ]

Eszerint nincs rowid Access-ben.

"Mindent azért kell tudni mert kérdezik, nem azért mert hasznos."

Ezek szerint mégse annyira egyértelműen könnyű a dolog...

@Goose-T
Köszi, szerintem valami ilyesmi lesz. Kitöröm őket, aztán beszúrok egy sort. Nem elegáns, de működik legalább.

[ Szerkesztve ]

"Mindent azért kell tudni mert kérdezik, nem azért mert hasznos."

Nem tudom, mi a frászt vársz, amikor az elején nekünk kell helyetted kitalálni az infókat, belőled meg harapófogóval kell kihúzni...
Ha szarul teszed fel a kérdést, talán ne lepődj meg, hogy nem kapsz egyből konkrét választ. És ne forgasd a szemeidet, ha már te kérsz segítséget...

Sk8erPeter

egyre több az indok az access adatbázisod kidobására, miért nem használod ki?

=Kilroy was here============================ooO=*(_)*=Ooo=======

Óh, olyan szívesen megtenném, hogy hajaj, de erről sajnos nem én döntök.

"Mindent azért kell tudni mert kérdezik, nem azért mert hasznos."

mondjuk elnézve a problémákat (amellett, hogy access ellenes vagyok), pont nem az access maga a probléma, hanem egyrészt szarul lett felépítve a használt adatbázis, másrészt a program is szarul lett megírva ami ilyen duplikációkat hoz létre bele.
Ezek a hibák, ha béna a programozó, pont ugyanígy megmaradnak, bármilyen db motort is használjon az ember.

Én kérek elnézést!

Beszúrsz egy plusz autonumber típusú mezőt és utána mát tudod törölni csak az egyiket...

JOGI NYILATKOZAT: A bejegyzéseim és hozzászólásaim a személyes véleményemet tükrözik; ezek nem tekinthetők a munkáltatóm hivatalos állásfoglalásának...

Ez nem jó, mivel nem módosíthatom ennyire az eredeti táblát.

A megoldás az lett, hogy COUNT-tal megszámoltam, hány ugyanolyan sor van, ha több, mint 1, akkor eltároltam az adatokat változókba, végrehajtottam a törlést, ami így mindkét bejegyzést törölte, aztán egy sima INSERT-tel beillesztettem 1 sort a régi adatokkal. Nem elegáns, de működik.

"Mindent azért kell tudni mert kérdezik, nem azért mert hasznos."

Kedves Uram,
Nem helyes amit írtál MSSQL alatt.

update table1
set valami = t2.valami
from table1 t1
join table2 t2 on t1.id = t2.id

helyette:

update t1
set valami = t2.valami
from table1 t1
join table2 t2 on t1.id = t2.id

Morcos voltam

Újabb gondom volna. Van egy TXT, benne mindenféle adat. Van egy ilyen:

SZ'MITÓGÉP+NYOMTATÓ

Ezt kellene beletenni egy VARCHAR típusú mezőbe. Mindig elszáll error-ral. Ha kicserélem a ' jelet mondjuk egy A betűre, akkor már megeszi. De nem csak itt, máshol se teszi be a ' jel miatt. Az adatot nem szeretném módosítani, egy az egybe tolja fel egy táblába a TXT tartalmát. Mit lehet ezzel csinálni, hogy megegye a ' jelet?

"Mindent azért kell tudni mert kérdezik, nem azért mert hasznos."

Duplázd meg a txt-ben az aposztrófokat, úgy már be fogja venni. Hogy jobban értsd: cseréld ki ezeket: ' erre: '' .

Szerk.: ne a hagyományos magyar kettős idézőjelre cseréld ("), hanem a szimpla aposztrófból tegyél kettőt egymás után(''), és azt egynek fogja venni az SQL.

[ Szerkesztve ]

Rockbandám: https://fb.me/scharlotterhodes *** Gitárelektronikai műhelyem: https://www.fb.me/goosetgitar

Ne konkatenált SQL beillesztést használj, hanem parametrizáltat. Azzal megeszi a "speciális" karaktereket is...

JOGI NYILATKOZAT: A bejegyzéseim és hozzászólásaim a személyes véleményemet tükrözik; ezek nem tekinthetők a munkáltatóm hivatalos állásfoglalásának...

A fenti kommentek alapján már próbáltam, de Delphi alatt valahogy sehogy nem bír összejönni a parametrizált SQL beillesztés. Természetesen most sem... Itt tartok:

SQLCode:='INSERT INTO sap.eszkoz VALUES ('+slTagok[1]+','+slTagok[2]+','+slTagok[3]+','''+slTagok[4]+''','''+slTagok[5]+''', ''szam'','''+slTagok[7]+''',TXT50)';
ZQuery1.SQL.Clear;
ZQuery1.ParamByName('TXT50').AsString := slTagok[8];
ZQuery1.SQL.Add(SQLCode);
ZQuery1.ExecSQL;

A hiba az, hogy TXT50 not found...

@Goose-T
Köszi, az ötlet jó, de ha meg lehet oldani, akkor módosítás nélkül szeretném.

[ Szerkesztve ]

"Mindent azért kell tudni mert kérdezik, nem azért mert hasznos."

Akkor Delphi-ben duplázd az aposztrófokat. Mi ezen a bonyolult?

Rockbandám: https://fb.me/scharlotterhodes *** Gitárelektronikai műhelyem: https://www.fb.me/goosetgitar

Tegyél egy kettőspontot a TXT50 elé a Query-ben (ParamByName-ben nem kell): [link]

JOGI NYILATKOZAT: A bejegyzéseim és hozzászólásaim a személyes véleményemet tükrözik; ezek nem tekinthetők a munkáltatóm hivatalos állásfoglalásának...

Oh, köszi!

Reggel 8 óra bújom ezt a szart, már jojózik a szemem, és egyszerűen nem vettem észre a példa kódban a kettőspontot.

@Goose-T
Nem bonyolult, csak plusz, felesleges művelet. Ha nem lehetne másképp megoldani, természetesen így csinálnám, de ezzel a paraméteres dologgal talán egyszerűbb.

"Mindent azért kell tudni mert kérdezik, nem azért mert hasznos."

Az volna az igazi, ha mindent paraméterrel illesztenél be. Akkor nem kellene az aposztrofozás a string mezőknél és az összes lehetséges string kódolási hiba kiszűrhető volna...

Erről beszélek

[ Szerkesztve ]

JOGI NYILATKOZAT: A bejegyzéseim és hozzászólásaim a személyes véleményemet tükrözik; ezek nem tekinthetők a munkáltatóm hivatalos állásfoglalásának...

Köszönöm a jó tanácsokat, igyekszem megfogadni!

"Mindent azért kell tudni mert kérdezik, nem azért mert hasznos."

Sziasztok! Tudnátok ajánlani valami könyvet, amiből elsajátíthatóak a DB kezelés alapjai?

I did nothing, the pavement was his enemy!

melyik adatbáziskezelő, és milyen megközelítésből (fejlesztői vagy üzemeltetői)?

90% üzemeltető + 10 % fejlesztés. Oracle + MS. De perpill csak nagyon alapok vannak. Nem tudom ismered-e, de CCNA vizsgára vannak szuper könyvek, amikből el lehet sajátítani nemcsak a Cisco berendezéseket, hanem a hálózatokat is. Na, szóval ilyen kellene adatbázisokra, ha létezik

I did nothing, the pavement was his enemy!

Oracle + Fejlesztői megközelítés:

Ebben a témában a Gábor András, Juhász István - PL/SQL programozás Alkalmazásfejlesztés Oracle 10g-ben című könyvek ajánlom.

A könyv egy alap SQL tudást (select, insert...) azért igényel.

Express Edition-t lehet localhostra telepíteni.

Tanulásra egyetemen ezeket használtuk (pontosítva az első kettőt, az utolsó kettő új lehet mert nem találkoztam velünk):

1
2
3
4

miért zavar? Sokmilliárdig nőhet az id-d. 1-2 kimarad, na és?

Én kérek elnézést!