Új hozzászólás Aktív témák
-
sanzi89
addikt
-
Sk8erPeter
nagyúr
válasz sztanozs #1291 üzenetére
Ja, hogy így. Igen, mondjuk adatbázisonként eltérhet a formátum, MySQL-ben ilyen: [link]
"MySQL retrieves and displays DATETIME values in 'YYYY-MM-DD HH:MM:SS' format. The supported range is '1000-01-01 00:00:00' to '9999-12-31 23:59:59'."MSSQL-ben: [link]
"Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds"Egyébként konkrétan azért kérdeztem vissza, mert feltételezem, a TÁROLÁS módja a háttérben (tehát magának az adatbázis-kezelőnek a szintjén) viszont általánosan van megoldva, tehát ez alapján magából a tárolt értékből ki lehet nyerni a megfelelő dátumot, legfeljebb lekérdezéskor előfordulhat, hogy valaki nem megfelelő formátumban adja meg a datetime-ot, és akkor nem azt az eredményt kapja, amit elvárt; vagy épp feltöltéskor más formátumban adja meg, mint ami az elvárt, és "rossz" datetime tárolódik, nem?
Mondjuk egy UNIX timestamp legalább valszeg mindenhol ugyanolyan.
"Ha sql parancsot konkatenálsz - amit ugye nem illendő - akkor ahány adatbáziskezelő annyi féle datetime megvalósítás"
Itt viszont nem értem, miért emeled ki a konkatenálást, mert elvileg akkor épp azért, amiről beszélünk, tök mindegy, hogy most konkatenálva adtál át rossz formátumot, vagy prepared statementként.Gondolom erre a képre gondoltál: [link].
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz sztanozs #1293 üzenetére
Attól függ, milyen prepared statementről beszélsz, mert most már nem egyértelmű számomra.
=========================
(#1294) rum-cajsz : jaja, ArchElf készítette, mert a t×künk tele volt a PHP topicban a sok konkatenált fosadék query-vel. Elég találó.
[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz sztanozs #1299 üzenetére
Még mindig nem értem, hogy ez önmagában miért oldaná meg azt, ha a fejlesztő vagy a user rossz inputot akarna megadni a datetime mezőhöz. A kiindulópont ez volt, erre állítottad, hogy ez egy megoldás lehet, de még mindig nem mondtad el, hogyan kínál ez áthidaló megoldást nyelvektől függetlenül.
===
(#1298) martonx : igen, de most nem ez a lényeg, hanem hogy ez hogyan oldja meg a rossz formátumok problémáját (ha már ez volt az állítás), amiről korábban szó volt.
Sk8erPeter
-
-
sanzi89
addikt
válasz sztanozs #1326 üzenetére
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."
-
sanzi89
addikt
válasz sztanozs #1334 üzenetére
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."
-
sanzi89
addikt
válasz sztanozs #1337 üzenetére
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."
-
cucka
addikt
válasz sztanozs #1551 üzenetére
Egyszerűen csak a szöveg alapú reprezentációt kell frissíteni és verziónként új adatbázist készíteni - nem pedig az aktuálist hozzáhegeszteni a fejlesztői verzióhoz. Ilyen módon az adatbázis felépítés (és a tárolt eljárásoik is) is egyszerűen verziókövethetővé válik.
Igen, ez így van. Lehet adatbázis deploy scripteket írni, nincs ezzel semmi gond. Az eredeti kérdésfelvetés viszont a php topikban volt, méghozzá azzal kapcsolatban, hogy a php kódban implementált alkalmazáslogikát megérné tárolt eljárásként megírni. Na ezzel így már problémák vannak:
- A php előnye, hogy a verziókövetőben található fileok halmaza és a futtatható kód egy és ugyanaz. Tárolt eljárásokkal elvesződik az előny.
- A legtöbb php-s projekt olyan kis léptékű, amin már egy adatbázis deploy script elkészítése és karbantartása is túlmutat.Nem azt mondom, hogy a tárolt eljárások ne lennének alkalmanként hasznosak, de abban a kontextusban, ahol felmerült a kérdés, egyáltalán nem tartom jó ötletnek.
A második szerintem csak sírás. Adatbázis oldalon bőven elég szerintem az a WSWG megoldás, ami a piacon elérhető - ha az nem felelne meg, amit a motorhoz adnak.
Mi az a WSWG?(#1555) martonx
Szvsz SQL fejlesztői környezetek közül a legjobb az SSMS, de Oracle vonalon a Toad for Oracle is jó (csak ronda, mint a bűn)...
Félreérthető voltam, amire utalni szerettem volna, az a programozási nyelv (mondjuk PL/SQL) és annak a szolgáltatáskínálata, na ez az, aminek 60-as évekbeli hangulata van.A többire kb. válaszoltam feljebb. A lényeg, hogy nem azt állítom, hogy tárolt eljárást írni rossz ötlet lenne, hanem hogy az esetek többségében nem ad semmilyen előnyt, cserébe növeli a komplexitást.
[ Szerkesztve ]
-
dellfanboy
senior tag
válasz sztanozs #1797 üzenetére
igazad van. való igaz, hogyha látja a táblákat nem biztos, hogy tud kreálni új táblákat.. ezt el is felejtettem, hétfőn megnézem tud-e kreálni.
azért nem kaptam jogosultságot mert vmi it biztonsági izé lépett életbe 0601-től... azokba a táblákba lévő adatok kellenek, így most ő futtatgatja le és küldi el nekem...
eladó dolgok:mondd az árát és vidd http://hardverapro.hu/tag/dellfanboy#aprohirdetesei
-
bbTamas77
aktív tag
válasz sztanozs #1856 üzenetére
Látom nem értitek mi a problémám.
Ha UNIX-ba számolok akkor kapok egy számot.
Tegyük fel van két dátum UNIX formátumba, egy jelen idő, és egy jövő idő.
A jövő idő egy nagyobb szám UNIX formátumba.
Azért nagyobb szám, mert az UNIX 1970. január 1. 00:00:00 számolja az időt.Ha a nagyobb UNIX számból(jövő időből) kivonom kisebb UNIX számot(jelen idő) kapok egy értéket.
Ha azt a külömbségből létrejött UNIX értéket alakítom át dátummá UNIX_TIMESTAMP() függvénnyel akkor 1970. január 1. 00:00:00 közeli dátumot kapok mert az onnét számolja.Különbséget kéne átalakítani, valahogy.
[ Szerkesztve ]
-
-
csabyka666
addikt
válasz sztanozs #2048 üzenetére
Köszönöm, akkor legalább ezt már értem.
Oké, a kapcsolótáblán keresztül felbontom a több-a-többhöz kapcsolatot. Lekérdezésnél mindenképp JOIN kell, ha például azt akarom megtudni, hogy egy adott áruházban milyen termékeket vásárolhatok meg?
Mert - érzésem szerint - valahogy mindenképp bele kell venni a kapcsolótáblát is a lekérdezésbe, de hogy hogyan, az egyelőre nekem rejtély.Ágdarálást, kaszálást, területtisztítást vállalok profi gépekkel! Elsősorban Zala megye és vonzáskörzete, de minden megkeresést meghallgatok. +36305633091
-
-
Ispy
veterán
válasz sztanozs #2103 üzenetére
Amíg egy 20-30 useres cég vígan elmegy MS SQL Express-szel, addig nem nagyon érdekel más alternatíva, akinek meg kevés, az meg vegye csak meg a nagy SQL Server-t (arról nem is beszélve, hogy az ügyfeleink 99%.a Microsoft termékeket használ szerver oldalon).
"Debugging is like being the detective in a crime movie where you're also the murderer."
-
válasz sztanozs #2106 üzenetére
A bármi az nem az ms sql express.
Te azt mondtad, hogy az ilyen express kiadásoknak lehet komoly alternatívája a pg. szerintem meg nem, fullos oracle-nek, ms sql szervernek, stb. bárminek lehet. ha meg az ora és a pg árazását hasonlítom össze... nem is kell folytatnom a mondatot.Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
jocomen
aktív tag
válasz sztanozs #2223 üzenetére
"1-sok" kapcsolattal: a Tábla2 kulcsa szerepel a Tábla1-ben is külső kulcsként, csak a példába nem írtam bele.
Mondjuk így nézne ki:Tábla2 PK:t2_id; c -----1-sok------- Tábla1 PK:t1_id; FK:t2_id; a; b.
Tábla1 "b" oszlopánál kéne megadni a következő kifejezést az Access számára érthető módon: =c*a
-
-
Apollo17hu
őstag
válasz sztanozs #2341 üzenetére
Nem kell bele.
Automatikus szövegkiegészítést és programkód-rendezőt (beautifier) használok: [w] + [space] lenyomására a "WHERE 1 = 1 AND" karaktersorozatot kapom. Az "1 = 1" miatt a beautifier a következő sorba rendezi az AND operátort és az azt követő feltételt, így ha ki kell kommenteznem, nem kell azzal bajlódnom, hogy a WHERE -rel egy sorban van, így az egész sort kommentezhetem duplakötőjellel.
[ Szerkesztve ]
-
zolynet
addikt
válasz sztanozs #2566 üzenetére
Nekem is volt már problémám az IN és NOT IN -es megoldásokkal, mostanában az Exists-el szoktam megoldani.
ez a megoldás még nem volt:
SELECT egyik_tabla.id
FROM egyik_tabla
where
not exists (select 1 from masik_tabla where masik_tabla.id=egyik_tabla.id)Egyszerű, átlátható, a feltételek is jól szűkíthetőek a továbbiakban.
[ Szerkesztve ]
Life is too short to stay stock!
-
pakriksz
őstag
válasz sztanozs #2770 üzenetére
lehet 2 mező kulcs? Úgy rémlik arra errort dobott, hogy dupla kulcs... ezért inkább hozzáadtam még egy mezőt, amibe az ip és a userid közös hash-je kerül, és az lett a kulcs
[ Szerkesztve ]
Troll (nemhivatalos definíció): az akinek véleménye nem tetszik nekünk/nem értünk vele egyet. (10-ből 9 fanboy ezt ajánlja) || Fanboy 8 in 1 (Intel, AMD, Nvidia, konzol, PC,+minden politikai oldal) hiszen "ahol nem mi vagyunk, ott az ellenség"
-
TomyLeeBoy
tag
válasz sztanozs #2857 üzenetére
Válaszolva a felmerülő kérdésekre:
Igen belegondoltam mit szeretnék, eddigi kódjaimban én is ezt a módszert követtem, hogy legeneráltam a megfelelő sql kérést, így ami nem kell az nincs ott a where-ben. Most viszont a sok táblakapcsolat és a sok where feltétel miatt gondoltam hogy jó lenne ha mindig minden ott lenne, megfelelő paraméterrel.
Egyébként sztanozs "WHERE T.mezo IN (SELECT mezo FROM Tabla)" megoldásával sikerült megoldani a problémát, és minden variációban jól működik így a lekérdezés.
Köszönöm!
[ Szerkesztve ]
Az idő sebessége: 1s/s
Új hozzászólás Aktív témák
- Samsung Galaxy A55 - új év, régi stratégia
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Milyen autót vegyek?
- Samsung Galaxy GT-S 3100 telefonba hol a rendeljek akksit?
- Mikrotik routerek
- Retro teló rajongók OFF topicja
- Apple notebookok
- Óra topik
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Eredeti játékok OFF topik
- További aktív témák...
- 8/16GB memoriák
- APPLE MacBook Air 2020 13" Retina - M1 / 8GB / 256 GB SSD / MAGYAR / 96% akku, 81 ciklus / Garancia
- LG NanoCell 55NANO766QA Halvány píxel csík
- Philips 58PUS8545/12 1 ÉV GARANCIA Játék üzemmód
- Tyű-ha! HP EliteBook 850 G7 Fémházas Szuper Strapabíró Laptop 15,6" -65% i7-10610U 32/512 FHD HUN