Új hozzászólás Aktív témák
-
L3zl13
nagyúr
Szvsz vagy valami viszonylag egyszerű scripttel átkonverálod az inserteket update-té, vagy létrehozol egy átmeneti táblát az adatbázisban, abba feltöltöd az insertekkel az adatot (Egy szövegszerkesztőben csere minddel átírod a táblanevet.) és utánna többsoros update-tel frissíted az éles táblát.
Elvileg az InterBase is tud többsoros update-et.UPDATE Country
SET CODE = (SELECT CODE FROM CountryTMP WHERE Country.ID=CountryTMP.ID),
SET NAME = (SELECT NAME FROM CountryTMP WHERE Country.ID=CountryTMP.ID),
SET CLASSIFIER = (SELECT CLASSIFIER FROM CountryTMP WHERE Country.ID=CountryTMP.ID),
SET CATEGORY = (SELECT CATEGORY FROM CountryTMP WHERE Country.ID=CountryTMP.ID),
SET ENABLED = (SELECT ENABLED FROM CountryTMP WHERE Country.ID=CountryTMP.ID);Csak akkor müxik, ha a beágyazott select-ek mindig csak egy sort adnak vissza.
[ Szerkesztve ]
Aki hülye, haljon meg!
-
nyunyu
félisten
Egyszerubb volt a problema, mint hittem.
Kulfoldi kollegak felvilagositottak, hogy amikor IBExperttel megnyitom a lementendo tablat, akkor a toolbarban megjelenik egy "export data" ikon, arra kattintva allithato, hogy "UPDATE statement", vagy "INSERT statement" formaban mentse el oket...
(Gondoltam, hogy van valami ilyesmi opcio, csak en a menusort nyalaztam at, ott meg csak az Export Metadata volt, ami nem igy mukodik.)
Hello IT! Have you tried turning it off and on again?
-
nyunyu
félisten
En lenni
Most jottem ra, hogy a gepemre felrakott Visual Studio 2008 feltett egy SQL Express 2005-ot, arra viszont siman be tudok jelentkezni az SQL Management Studio 2008R2-mmel, at is importaltam az adatot, SQLExpress 2005 alatt backup, celgepre atmasol, SQL2005 alatt siman restore.
Feleslegesen szivtam az adat attoltessel 6-7 orat
Mondjuk azt meg mindig rejtely, hogy a sajat gepen futo 9.0.4053-as SQLExpress 2005-re miert tud rakapcsolodni, mig a masik gepen futo 9.0.4053-as SQL 2005-re meg miert nem.
[ Szerkesztve ]
Hello IT! Have you tried turning it off and on again?
-
martonx
veterán
Szia!
SMSS2008R2 simán kezeli az SQL 2005-öt, én is így használom a melóhelyen.
Lebackupolni is tudod 2008-at 2005-re, csak a backup options-nél be kell állítani a cél SQL formátumot (mondjuk 2005-re).SMSS full telepítéskor kapsz egy SMO-t is, amivel tudsz komplett adatbázist scriptekké alakítani. Plusz van egy 3rd party ingyenes kiegészítő is ehhez, (szintén SMO-t használja, csak felhasználóbarátabb, bár szintén parancssoros) de nem jut eszembe a neve. Valahol codeplex-en megtalálod.
Remélem mindenre válaszoltam.
Én kérek elnézést!
-
martonx
veterán
bocsi, rosszul mondtam neked nem a backup kell, hanem kettővel alatta a Generate Scripts.
Ott ha végig csinálod a varázslót, akkor:
1. be tudod választani, hogy az adatok is belekerüljenek a scriptekbe (mondjuk egy 10 gigás adatbázisnál nem túl szerencsés)
2. be tudod állítani a cél SQL szerver verzióját.Én kérek elnézést!
-
-
Apollo17hu
őstag
Ilyet én is szoktam csinálni. Az a feladat, hogy megadott feltételek szerint válogassam ki a szükséges néhánytízezer rekordot egy segédtáblába, amivel később a hónap folyamán dolgozunk. A rekordokat könnyű kiválasztani, de kb. 100 attribútum tartozik hozzájuk, azokat pedig 20-25 adattáblából kell összeszedni. Ha ezeket mind egyetlen lekérdezésbe írnám, az életben nem futna le. (Optimalizáláshoz nem értek, az IT-segítség pedig sok lóvéba kerül. ) Ezért a leválogatott rekordokhoz később, UPDATE-ekkel keresem ki az attribútumokat - akár egyesével az eddig fel nem használt adattáblákból.
-
Ispy
veterán
Pedig teljesen standard dolog, én is sokat használom tárolt eljárásokban, például összetett lekérdezéseknek inkább csinálok egy temp táblát és ott rakom össze az adatokat.
Igaz nem a wheres megoldással, nekem arra nem áll rá az agyam, de gondolom megszokás kérdése.
"Debugging is like being the detective in a crime movie where you're also the murderer."
-
-
nyunyu
félisten
Majdnem.
year, month eredmenyet vissza kell castolni varcharra, kulonben nem hajlando osszefuzni a stringekkel.
Illetve az is problema, hogy az egyjegyu honapoknal nem teszi ki a nullat a honap ele, igy az osszefuzott string '2013.8' lesz.Igy vagy kezzel atirod a tablaban az ertekeket ilyen formara, vagy lehetne bonyolitani a lekerdezest CASE-sel, de szerintem egyszerubb kettebontani a ho oszlopot ev+ho-ra, aztan utana egy szimpla query is megteszi:
SELECT * FROM honapok WHERE ev = YEAR(CAST(vizsgaltnap AS DATETIME)) AND ho = MONTH(CAST(vizsgaltnap AS DATETIME)) AND lezarva = 1Hello IT! Have you tried turning it off and on again?
-
Petya25
addikt
Bakker a formátum volt a hunyó, működik.
A vizsgáltnapot szétbontottam és közé tettem a kötőjelet.
+ e + "-" + h +
És így az Rst.RecordCount pozitív találatkor már megszámolta a sorokat ami 0-nál nagyobb.
Kiváltódik az esemény.
Köszi a tippet.Antonio Coimbra de la Coronilla y Azevedo, bizony!
-
martonx
veterán
"Viszont ez durvan 200x lassabb kodot general, mint ha megirnad SQLben, es feladnad rendes querykent, ahol viszont nem biztos, hogy minden esetre gondoltal, es kimaradhat valami..."
Újabb EF-eket (5-6) használva, ezzel azért vitatkoznék, bár nyilván ha valami szuperbrutál 30 soros LINQ kifejezést írtál, akkor azzal elszuttyog a LINQ, míg SQL-t csinál belőle. Egy Entity.Add eset viszont korántsem 200X lassabb, mint egy kézzel megírt, rendesen SqlParameter-ezett SqlCommand.
Én kérek elnézést!
-
nagyúr
úgy néz ki, valami elkúrt módon lett létrehozva ez a db ebből a szempontból, ezért viselkedik máshogy kb. minden klienssel.
Tudod, mit jelent az, hogy nemezis? Az érintett, erősebb fél kinyilatkoztatása a méltó büntetés mértékét illetően. Az érintett fél jelen esetben egy szadista állat... én.
-
bpx
őstag
select * from (
select * from (
select
pilota, sum(pont) over (partition by pilota) as sum_pont,
vegeredmeny,
row_number() over (partition by pilota order by vegeredmeny) rn
from futam) where rn <= 4
) pivot
(min(vegeredmeny) for rn in (1 as er1, 2 as er2, 3 as er3, 4 as er4))
order by sum_pont desc;De szerintem MySQL lesz a kérdés.
-
bandi0000
nagyúr
-
galocza
aktív tag
köszönöm a választ.
igen, a fülükbe toll...
1. kábelcserét elvileg én is meg tudom oldani, s így, hogy szerinted lehet az, akkor meg is fogom tenni.
2. ezzel sokat nem tudok tenni, de a leírt nem állandó probléma, hanem mintha néha "beakadna". gondolom, ha az általad leírt dolog lenne, akkor teljes káosz, anarchia, pandemonium lenne.*itt vesztettél el teljesen. gondolom nem összeegyeztethetőek... 8)
-
oh my god de ronda...
szerencsére nem oracle-ről van szó...a gondolatmeneted az, amit én is kitaláltam.
logikai kifejezést char-ra konvertálni, majd vissza logikaivá, annak nem sok értelmét látom.
köszönöm uram, hogy nekem postgresql jutott
[ Szerkesztve ]
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
-
"NOT IN vs LEFT JOIN?": értem, amit írsz, de.
a calendar tábla évi nagyságrendileg 20 rekorddal bővül, és mivel a subselectben van dátumra való korlátozás, így amikor ez végrehajtódik, akkor néhány rekord kerül a not in (...) -be. ennyivel boldoguljon már.annak utána fogok járni, hogy az áthelyezett szombat az én problémám szempontjából minek számít. kösz a felvetést.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
Louro
őstag
Köszi az infót. Általában éjfél után fél perccel indítjuk jelenleg is az átmásolást és van, hogy 7-ig is eltart :/ Az éles is lassan 1 terra. De ennek egy töredékéről készítünk tükörmásolatot.
Úgyis lassan várható egy kis fejlesztés a 2012-re. Lehet ezt a repikációt bedobom. A DBA-nk szerencsére jó szaki. Lehet tud is erről, csak több, mint 10 éve nem nyúltak a jelenlegi rendszerhez :/
Köszi mindkettőtöknek!
Mess with the best / Die like the rest
-
Louro
őstag
A rendszer egy dobozos termék. Az adatbázisa is adott. Azon változtatni nem tudunk. Ezért a második opció az életképes. Egy 2008->2012 frissítésért is kuncsorogni kellett De így is lassan 10 éves lesz az új szoftver is. (Multikulti probléma.)
A DBA-nk optimalizálásba próbál segíteni, de mivel nem csak ezen dolgozik, így elég kevés ideje jut az ilyen dolgokra. Úgymond ránk bízza, hogy milyen kódot írunk. Ha több millió sor törlését indítjuk el vagy deadlock-ba botlunk, akkor természetesen jön és segít. De nem fér bele az idejébe, hogy monitorozza a tevékenységeinket.
Elvileg mi is meg tudjuk nézni a query plan-t és tudunk eszközölni javításokat. (De a felhasználók közül csak én vagyok olyan beteges, akinek számít a futási idő. Többieknek csak az számít, hogy lefusson.) Mondjuk meg szoktam osztani praktikákat, de onnan az ő felelősségük, hogy alkalmazzák-e.
A partícionáláson én is gondolkodok, mert van jó pár gyakran használt nagy táblánk, amin segítene. Csak elmagyarázni a többi felhasználónak, hogy mit hogyan.... IF vagy egy WHILE ciklusnál is teljes sötétség. Vagy, ha kell, inkább kézzel töltenek be 100 külső forrást, semmint ciklussal BULK INSERT-tel.
(Desszert: Egyik korábbi munkahelyemen meg VIEW-kat kezdtük el visszafordítani, hogy miből is épül és a 13. szint után feladtuk. VIEW-ra VIEW-t, majd arra VIEW-t építeni...Sok a szakbarbár a piacon, de persze ők sírnak a legjobban a pénzért.).
Bocsi a hosszért... Megyek eszek sütit. Nem panaszkodom. A replikációt biztos megbeszélem az DBA-val és a partícionálás nagyon terítéken van, mert sokat nyernénk vele.
Mess with the best / Die like the rest
-
-
Jim Tonic
nagyúr
Igen, ezt értettem dupla select-en. Jelenleg hasonlóan írtam meg, de ez a rank() felkeltette az érdeklődésem. De ez csak tsql, asszem.
szerk.: Apollo row_number() függvénye alapján jutottam el a rank()-hez. Köszönöm.[ Szerkesztve ]
Alcohol & calculus don't mix. Never drink & derive.
-
nyunyu
félisten
Jut eszembe, ezt is lehetne egyszerűbben írni:
SELECT
y.nev,
MAX(ar) max_ar
FROM t_cikk x
INNER JOIN t_tarsasjatek y
ON x.tarsasjatek_id = y.id
GROUP BY y.nev
ORDER BY MAX(ar) DESC;De amennyire emlékszem Oracle nem nagyon szokta szeretni, ha számolt oszlopokra próbál rendezni az ember, sokszor kaptam hasonló próbálkozásokra szintaktikai hibát, emiatt írtam inkább köré egy másik selectet a rendezéssel.
Más adatbáziskezelők rugalmasabbak ebben.
[ Szerkesztve ]
Hello IT! Have you tried turning it off and on again?
-
bpx
őstag
Konstans értéket nem kell a group by-ban felsorolni.
De, tud alias alapján rendezni.
Nem, nem tud oszlopszám szerint csoportosítani.select
1 + 2 as harom,
null as ertek2,
created as letrehozva,
sum(user_id) as valami,
count(*) as darab,
'hello' as ertek3
from
dba_users
group by
created
order by
harom,
letrehozva
;
HAROM E LETREHOZVA VALAMI DARAB ERTEK
---------- - ------------------- ---------- ---------- -----
3 2020-04-16 19:04:45 6442450869 6 hello
3 2020-04-16 19:04:46 13 1 hello
3 2020-04-16 19:06:12 43 2 hello
3 2020-04-16 19:06:18 23 1 hello
3 2020-04-16 19:07:31 2147483638 1 hello
3 2020-04-16 19:08:08 36 1 hello
3 2020-04-16 19:15:29 48 1 hello
3 2020-04-16 19:15:31 49 1 hello
3 2020-04-16 19:15:37 101 2 hello
3 2020-04-16 19:18:29 61 1 hello
3 2020-04-16 19:18:41 62 1 hello
3 2020-04-16 19:20:21 70 1 hello
3 2020-04-20 20:51:53 73 1 hello -
Louro
őstag
Én is mellőzöm a right join-t, mert az agyunk balról jobbra értelmez. De, amikor mondja, hogy mi a feladat és hogyan kezdet neki, akkor ott volt,hogy right kellett volna. Amikor nagyon junior voltam, szégyeltem volna olyan kérdéseket feltenni, mint amiket én kapok manapság.
A senior-nak is már ajánlottam az sqlzoo.net oldalt és tegnap találtam az Oracle oldalán is egy tök jó leírást kezdőknek, ahol elég sok példa mentén van elmagyarázva.
Kicsit ON is legyek. Már 8 éve SQL-ezek. Bár nem tartom magam veteránnak kódismeret szintjén, de 5 év Oracle és most 3 év T-SQL a hátam mögött kicsit tovább lépnék. DBA irány szimpatikus. Van olyan iskola, ami különösen ajánlott vagy nagyon kerülendő?
Mess with the best / Die like the rest
-
bpx
őstag
Ezek az Oracle saját tanfolyamai. Mindenhol ennyi lesz az ára nagyságrendileg és a tananyag is ugyanaz lesz. Az Oracle Hungary az oktatási részlegét leépítette, az oktatási partnerek tartják nekik a tanfolyamokat.
Több helyen is vannak egyedileg egyeztetett tematikájú ás formátumú oktatások is. Ezek ár/értékben kedvezőbbek. Talán.
De igazából egyik változattal sem vagyok megelégedve.
Az említett Webváltónál dolgozom, 10 éve. Nem foglalkozom oktatással, csak ha nagyon muszáj.
-
nyunyu
félisten
Közben találtam egy másik megoldást, ami nem a JOINnál szűr, hanem CASE WHEN-ekkel pakolja külön oszlopokba az egyes tételeket:
SELECT p.projectName 'Project Name',
SUM(CASE WHEN pc.costCategory='Cost category1' THEN pc.cost ELSE 0 END) 'Cost category1',
SUM(CASE WHEN pc.costCategory='Cost category2' THEN pc.cost ELSE 0 END) 'Cost category2',
SUM(CASE WHEN pc.costCategory='Cost category3' THEN pc.cost ELSE 0 END) 'Cost category3',
SUM(CASE WHEN pc.costCategory='Cost category4' THEN pc.cost ELSE 0 END) 'Cost category4'
FROM Project p
LEFT JOIN ProjectCost pc
ON pc.projectID=p.projectID
GROUP BY p.projectName
ORDER BY p.projectName;De ez sem sokkal olvashatóbb
Jut eszembe, hasonló példával szívatott a mostani főnököm 3 éve állásinterjún.
Aztán nemsokkal később belebotlottam kolléga kódjába, ami 10 attribútum nevét és értékét feszíti ki egy termék sorra ugyanígy
Azóta sem mertem átírni PIVOTra.[ Szerkesztve ]
Hello IT! Have you tried turning it off and on again?
-
Ispy
veterán
Én így szoktam, csak annyi, hogy általában egy tárolt eljárásban, ezért az első select csak kategóriákat adja vissza értékkel, a második meg oszlopokba rendezi summal. Így egy fokkal olvashatóbb.
"Debugging is like being the detective in a crime movie where you're also the murderer."
-
Szmeby
tag
És gondolom, a projektben résztvevő összes cég azt állítja magáról, hogy csak minőségi szoftvert adnak ki a kezükből, a szakmai kiválóság az elsődleges.
Szerintem amúgy nem szar a terv, csak a tervező bizonyára elfelejtette, hogy a munkája nem ér véget a Generate gomb megnyomásával. A többi résztvevő meg nem volt elég tökös visszadobni a félkész produktumot. Pénz van, idő nincs, nyilván a gányolás felé húz ezek után minden résztvevő szíve. Nem szar ez, hanem kihívásokkal tűzdelt. Azt meg minden fejlesztő szereti, sokan a cv-be is beírják, a kihívás fontos.
(Sosem értettem, miért nem illik megosztani a nyilvánvaló ostobaságokat elkövető (jogi) személyek / projektek nevét. Mások okulására és tájékoztatására, hogy "ide ne gyertek dolgozni, ha nem akartok inkompetens, egyeztetésre képtelen egyedekkel együtt dolgozni". Mindig csak a cukormáz látszik. Pedig hibázni jó dolog, de azt nem beismerni totális káoszba vezet. És kinek van kedve káoszban létezni? Habár biztos akad olyan is, de én nem tartozom közéjük.)
-
Louro
őstag
Igazán "minőségi" megoldás az lett volna, ha készül egy dictionary arra, hogy táblanév-oszlopnév-oracle táblanév-oracle oszlopnév
A szabványok jók és hasznosak, de azért néha nem árt frissíteni azokat.
@Szmeby: Szerintem a beszállítókat nem hibáztathatjuk, mert lehet elhangzottak ellenérvek. De a megrendelőnek/ügyfélnek mindig igaza van. Az se igaz, hogy minőségi cég nem végez kontár munkát. Van az a pénz.
Nálunk - pénzintézet - szintén az évek az alatt olyan igények születtek, hogy már csoda, hogy működik a rendszer. Mindig kértek valamit. Félig leszállították, mert gyorsan kellett valami. De a végét már nem rendelték meg, mert addig volt rá működő workflow. És az igények is olyanok .... . Régiek közül persze már szinte senki sincs. Szóval, ha kérdés merül fel, szép kutató munka.
Mess with the best / Die like the rest
-
Szancsó
aktív tag
Köszönöm!
Ismeri a 2.5 is, az analitikus függvények viszont ha jól emlékszem csak 3 -tól vannak, de CTE -vel más módon szerintem megoldom majd. Csak olyan ritkán kell DB -t piszkálnom, hogy már elfelejtem melyik mit is tudMy story is one of many thousands, and the world will not suffer if it ends too soon.
-
nyunyu
félisten
Lehet, hogy az első logikája érthetőbb lenne CTE szintaxissal:
with utolso_tankolas as
(select rendszam,
max(datum) max_datum
from tankolas t
group by rendszam)
select
t.datum,
t.rendszam,
t.km
from tankolas t
join utolso_tankolas t2
on t.rendszam = t2.rendszam
and t.datum = t2.max_datum;Hello IT! Have you tried turning it off and on again?
-
-
-
DeFranco
nagyúr
Köszönöm szépen, nagyjából működik de nem teljesen:
1: a sum(ertek)/osszegre ugrik az ellenőrzés, nem fut le, a hibaüzenet az alábbi:
ORA-56902: összesítő függvényt várható a forgatási műveletben
56902. 0000 - "expect aggregate function inside pivot operation"
*Cause: Attempted to use non-aggregate expression inside pivot operation.
*Action: Use aggregate function.2: ez csak nekem kérdés mert még nem vagyok otthon pivotban: ha sum(ertek)-en hagyom tehát nem képzek indexet, akkor az eredménytábla úgy néz ki hogy ezeket az oszlopokat pakolja egymás mellé:
egyedi_azonosito II o.osszeg II A II B II C II stb.
tehát az [o.osszeg] oszlopot a pivotolt résztől függetlenül beteszi a "sorfej" és az "oszlopok" közé
Ez azért van, mert a pivotnál mindent sorfejlécnek értelmezünk ami nincs benne a sum és a for mezőkben és az a lekérdezés sorrendje szerinti hierarchiában alábontást jelent?