Hirdetés
- GoodSpeed: A RAM-válság és annak lehetséges hatásai
- bb0t: Ikea PAX gardrób és a pokol logisztikája
- Luck Dragon: Asszociációs játék. :)
- GoodSpeed: Márkaváltás sok-sok év után
- Sub-ZeRo: Euro Truck Simulator 2 & American Truck Simulator 1 (esetleg 2 majd, ha lesz) :)
- sziku69: Fűzzük össze a szavakat :)
- ldave: New Game Blitz - 2025
- Real Racing 3 - Freemium csoda
- Gurulunk, WAZE?!
- Brogyi: CTEK akkumulátor töltő és másolatai
Új hozzászólás Aktív témák
-
DS39
nagyúr
válasz
sztanozs
#3052
üzenetére
Szerintem túl gondolkodjátok az eredeti kérdésemet
Egyik adattáblából kinyert adatot, felhasználok egy másik adattáblából történő lekérdezéshez.az egyetlen bemenő paramétert az SSMS-ben írom bele a scriptbe futtatás előtt.
nem egy állandóan futó valamiről van szó, hogy kellene hozzá program. -
DS39
nagyúr
válasz
sztanozs
#3043
üzenetére
nem tárolt eljárás, csak egy lekérdezés.
de az alábbi megoldás végül is tökéletes nekem.
az amit írsz nem jó (vagy én értem félre)
ha az alábbi kódrészlethez hozzáteszem ezt:
declare @j int = @i - 1és beteszem egy plusz oszlopba a @j-t ,akkor annak minden sorban fix marad az értéke, nem végzi el megjelenített soronként a műveletet.
-
#2862
TomyLeeBoy
tag
sztanozs
#2857
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!
-
zolynet
veterán
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.
-
#2343
Apollo17hu
őstag
sztanozs
#2341
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.
-
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
-
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. -
Ispy
nagyúr
-
#2049
csabyka666
veterán
sztanozs
#2048
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. -
-
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.
-
#1798
dellfanboy
őstag
sztanozs
#1797
dellfanboy
őstag
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...
-
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.
-
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. -
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. -
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.
-
#1300
Sk8erPeter
nagyúr
sztanozs
#1299
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.
-
#1295
Sk8erPeter
nagyúr
sztanozs
#1293
-
#1292
Sk8erPeter
nagyúr
sztanozs
#1291
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].
Ezért kértem itt segítséget
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Elég találó. 
Új hozzászólás Aktív témák
- Szép! Lenovo Thinkpad T14s G2 Üzleti "Golyóálló" Laptop 14" -50% i7-1185G7 4Mag 16GB/1TB FHD IPS
- Szép! Lenovo Thinkpad T14s G2 Üzleti "Golyóálló" Laptop 14" -50% i7-1185G7 4Mag 16GB/512GB FHD IPS
- Dell PowerEdge T110 II PC, Xeon E3-1220 v2 CPU, 32 GB DDR3 RAM, 2 x 1 TB SAS HDD
- Lenovo Tab M10 HD 64GB, Kártyafüggetlen, 1 Év Garanciával
- HyperX Fury DDR4 - 3200 - CL16 - 16GB RAM (8GB x 2) RGB
- Samsung Galaxy A53 5G 128GB, Kártyafüggetlen, 1 Év Garanciával
- Apple iPhone 13 Pro / 128GB / Kártyafüggetlen / 12Hó garancia / Akku : 100%
- BESZÁMÍTÁS! ASUS TUF B760M i9 14900K 32GB DDR4 1TB SSD RX 7900 XTX 24GB ZALMAN Z1 Plus Seasonic 850W
- Laptop felvásárlás , egy darab, több darab, új , használt ! Korrekt áron !
- ÁRGARANCIA!Épített KomPhone Ryzen 7 7800X3D 32/64GB RAM RTX 5070Ti 16GB GAMER PC termékbeszámítással
Állásajánlatok
Cég: BroadBit Hungary Kft.
Város: Budakeszi
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest