- HiFi műszaki szemmel - sztereó hangrendszerek
- Milyen egeret válasszak?
- Kormányok / autós szimulátorok topikja
- Végleg lemondott a régi gépekről a Steam
- Milyen belső merevlemezt vegyek?
- Milyen TV-t vegyek?
- NVIDIA® driverek topikja
- 3D nyomtatás
- Milyen asztali (teljes vagy fél-) gépet vegyek?
- AMD Ryzen 9 / 7 / 5 9***(X) "Zen 5" (AM5)
Új hozzászólás Aktív témák
-
Louro
őstag
válasz
martonx
#6000
üzenetére
Uh, ilyen nálunk is van az egyik területen. Kb. 3-4 hetente felhívom a figyelmüket, hogy rendezzék már az adataikat. Ugyanarra a témára, naponta hoznak létre táblákat és van, hogy 1-2 rekord van csak benne. Mondtam nekik, hogy +1 oszlop, ami a napot jelöli, sokkal ideálisabb lenne. Ehelyett már 300+ táblájuk van csak egy célra és nekik így jó. Szerencsére csak két ilyen fafejű kolléga van. Persze panaszkodni tudnak, hogy ha az SSMS-ben lenyitják a táblák listáját, akkor van, hogy megnyekken a rendszer.
És nem egy DWH területről beszélünk. Kb. 100 táblában elférnének, de ehelyett 5000+ táblájuk van. Nekem fizikailag fáj, ha velük kell foglalkoznom. Hiába jelzem, hogy ha unique indexet akarnak trigger miatt, akkor ne 4 adatból rakják össze, amik ráadásul eltérő adattípusúak, hanem csináljanak egy dedikált unique mezőt és arra lehet indexálni.
De hát mi csak csóró üzemeltetők vagyunk és ők a détaendzsinírek.
-
Louro
őstag
válasz
shipfolt
#5971
üzenetére
Tanulási vagy munkacél? Utóbbira a licensz lehet probléma.
Előbbire:
- nagyon alapokra az sqlzoo.net oldalon az alap sql-t elég jól meg lehet tanulni.
- ha már kicsit komolyabb tanulás a cél, akkor a Microsoftnak az sql server management studio elérhető. Van hozzá egy egész jó példa adatbázis is, amit adventureworks néven találsz meg. (Telepítés kicsit ijesztő lehet.)
- ha youtuberek is beleférnek ide, akkor Pinal Dave és Bert Wagner egész jó videókat készítettek már. -
Louro
őstag
válasz
shipfolt
#5959
üzenetére
Én úgynevezett triggerben gondolkodnék elsőre.
bambano iránya tényleg jó, hidd el. Legyen egy új oszlopod, aminek a neve Esemény. Az egyszerűség kedvéért számokkal érdemes jelölni, de ha kicsi a tábla és van dögivel hely és kakaó, akkor szövegesen is beírhatod.
Szóval ez úgy nézne ki, hogy tegyük fel az első eseményed: létrehozás. Azaz itt létrehozod a feladatot (ID). Második esemény lehet mondjuk a feladatkiosztás. Itt legyen az a feltétel, hogy ha a Hatarido kitöltésre kerül.
CREATE TRIGGER séma.triggerNeve
ON séma.táblaNeve
AFTER UPDATE AS
BEGIN
SET NOCOUNT ON;
IF UPDATE (Hatarido)
BEGIN
UPDATE séma.táblaNeve
SET Esemeny = 'Feladatkiosztás'
FROM séma.táblaNeve S
INNER JOIN Inserted I
ON S.ID = I.ID
END
ENDMásik gondolatom a feladatot sokadszor olvasva, hogy azt akarod, hogy van a táblád és ha másik táblában rögzítenek Eseményt, akkor az a tábládon hajtson végre valamit. Igazából itt is triggert látom a legjobbnak. Csak akkor annyiban módosul a fenti script, hogy a 2. sorban, a tábla neve a másik táblára mutasson és a belső update-nél is az ON-nál érdemes figyelni a kötésre. Az Inserted-et úgy képzeld el, mint egy átmeneti tábla, amiben a 2. sorban hivatkozott tábla adott rekordja van (, amire elsül a trigger). Ilyenkor a legfrissebb adatokat tartalmazza. Ennek párja a "deleted", ami a frissítés előtti állapotot tárolja. Akadnak helyzetek, amikor vagy ez vagy az kell. De többnyire inkább a friss kell. Ha nem jegyzed meg, akkor általánosságban inkább használd az Inserted átmeneti táblát.
Szóval úgy érzem triggereket fogsz gyártani
(Max jönnek az okosabbak és mutatnak jobb megoldást. Munka után, agymosottan ezt tudtam segíteni.)Extra javaslat: Ha 4-5 lépés van a folyamatban, akkor érdemes eltárolni az időpontot és a felhasználót. Ha több, akkor lehet egy táblát csinálnék, hogy tároljuk el a lépést, időpontot és a nevet. Később jól jöhet.
-
Louro
őstag
Sziasztok!
T-SQL, SQL Server 2016
Tegnap óta rágódok egy feladaton, hogy miképp lenne a leghatékonyabb megcsinálni. Lehet megmosolyogtató, de vannak buktató.
A végcél:
A nehézséget az okozza - , hogy elsősorban, hogy fafejű főnökök vannak, így kötött a forma -, hogy az oszlopnevek dátumok. Ezzel nem is lenne igazából bajom.
A. verzió:
Agyaltam rajta, hogy ennek a transzponáltját csináljam-e meg. Mondhatni egy SELECT és sok-sok aggregált függvénnyel könnyen előállnak az adatok egy lépésben. De van a riportban 3 sor, amiben ragaszkodnak a % jelhez. Ha ezt az aggregáltba beteszem, akkor az unpivot során, amikor a végleges formára hoznám, nem tudja feldolgozni, mert eltérő az adattípus.
A/1. verzió: amikor az aggregált számokat előállítom, mindent szöveggé alakítom és tudok unpivot-tal élni.
A/2. verzió: A speciális jelet kihagyom, majd a végleges nézetre hozáskor soronként végigiterálva megkeresem azt a 3 sort és betoldom a százalékjellel.B. verzió:
Ettől tartok, hogy überciki, de aztán lehet mégsem. Létrehozom a végleges formához a táblát. Mindig létrehozok egy új oszlopot a kívánt névvel és annyi update-et írok, amennyi sorom van. Így a speciális karakterek is könnyen kezelhetőek és módosítás/bővítés is talán átláthatóbb.Utálom a túlbonyolított, átláthatatlan kódokat. Ha kell, áldozok a performancia oltárán, mert nem több száz milliós táblákkal kell dolgozni szerencsére.
Bevallom az A/1. verzió most ugrott be, mikor elkezdtem írni. Ez tűnne a legideálisabbnak, mert az aggregált függvényekben ott lesz az üzleti logika ( SUM(CASE WHEN...)) ).
Esetleg valakinek valami javaslata?
-
Louro
őstag
válasz
Petya25
#5942
üzenetére
Én eleve úgy szoktam mezőt létrehozni, hogy
create table [táblanév](
id bigint identity(1,1)
)Bár utólag is megoldható:
alter table [táblanév]
add id bigint identity(1,1)Ekkor 1-essel kezd és mindig eggyel növeli a mező értékét. Ha keletkezik egy új rekord, akkor megkapja a következő futószámot.
Remélem ez jó. A randommal az a bajom, hogy fontos-e az egyediség. Ha igen, akkor azt figyelni, hogy ki lett-e osztva az adott sorszám....De, ha nagyon beteg azonosító is jó, akkor:
alter table [táblanév]
add id varchar(1000)update [táblanév]
set id = newid()Ez elég random. A rand() függvénnyel meg generáltatsz egy véletlenszámot és azt írja be a mezőbe. Nem rekordonként generál egy számot. Ezért kaptad mindenhol ugyanazt.
-
-
Louro
őstag
válasz
sztanozs
#5790
üzenetére
Sajna van egy olyan társosztály, akik adattáblából dolgoznak. Kb. a jobbklikk->select top 100 rows funkciót ismerik. Próbáltam, hogy kiexportálom nekik és dolgozzanak Excelből, így nem kellene felesleges telepíteni ssms-t nekik. De fafejű a főnökük és a "régen is így csináltuk és működött" elvet követi :/
Mivel van egy igényük van és én hülye mondtam, hogy sokat kell görgetni és a képernyő nagy része kihasználatlan, akkor dobjuk be 10 oszlopba és már talán görgetés nélkül ott lesznek nekik, amik kellenek.
Sajnos a hülye vezetőkkel ellen én kevés vagyok.
-
Louro
őstag
Sziasztok!
Egy érdekes kérdéssel jönnék. Tuti van valami jobb megoldás, ami nekem beugrott.
Adottak listák. A listák 50-100 eleműek. Azért, hogy ne kelljen a kedves felhasználóknak sokat görgetniük, 10 oszlopban felsorolni.Példa: legyen a lista 22 elemű.
1 - 2 - 3 - 4 - 5 - 6 - 7 - 8 - 9 - 10
11 - 12 - 13 - 14 - 15 - 16 - 17 - 18 - 19 - 20
21 - 22Én arra gondoltam, hogy adok egy row_number()-rel sorszámot. Majd megnézem, hogy mod 10 mennyi. Így meglehetne, hogy melyik melyik oszlopba kerül. Majd egy újabb lépésben adok neki "sorszámot". Így már tudnám pivotálni. De gyanítom, hogy túlontúl túlbonyolítottam egy egyszerűnek tűnő feladatot.
Környezet: sql server 2016.
-
Louro
őstag
Én Oracle-ben találkoztam vele először. Bár azóta inkább az sql server mellett tettem le a voksom. Szerintem a legtöbb helyen elérhető.
Én úgy szoktam mondani, hogy ha 1-2 alkalommal kell, akkor performancia sokadlagos. Az eredmény legyen jó. De ha már ütemezett feladat lesz belőle, akkor megnézem a végrehajtási tervet és próbálom keresni a költséges pontokat. -
Louro
őstag
Sziasztok!
Egy kis performanciális kérdésem lenne. Sql server 2016-os az alap. Kkb. 5-10GB-os adattáblák. Azokat másolom át napi rendszerességgel. Persze nem sok, de hátha van gyorsabb megoldás.
Először ürítem a táblát (truncate). Indexeket kikapcsolom. SSIS Data Flow segítségével áttöltöm a táblát. Majd a clustered indexet, azután a többi indexet újraépítem.
A maxconcurrentprocess -1 értékre állítva, hogy kimaxoljam a CPU-t. A buffer alaphelyzetben, 10 MB/10000 rekordonként másol.
-
Louro
őstag
válasz
sztanozs
#5617
üzenetére
Én a T-SQL megoldást jobban csíptem. Nem voltak túlbonyolított jobok. Kisebb ellenőrző riportok, töltések. Csak most kitalálták az anyacégnél, hogy mindent át kell ültetni.
Az okot nem tudom. De mivel akad néha valami módosítás, ami igényli, hogy hozzányúljuk meglévő folyamatokhoz. Eleve nem túl gyors és viszonylag sűrűn omlik össze a Visual Studio. Félek, hogy ez durván lassítani fog. Ezért gondoltam ,hogy a tárolt eljárás kiskapu lehetne, hogy gyorsan szűrhessek. Anno Excelbe elkezdtük adminisztrálni, hogy melyik job mit tartalmaz, de hamar hamvába halt, hogy nem cska ketten csináltuk. Vagy mindenkinek kellene vagy senkinek. -
Louro
őstag
Sziasztok!
Újabb SQL szerveres kérdés. Elgondolkodtam egy dolgon. Nálunk van egy kezdeményezés, hogy a meglévő jobokat ültessük át SSIS package-ekre. Ezzel nem is lenne gond. Hisz copy-paste a nagy része. De!
Ha volt valami változás a forrásban vagy szűrést kell bővíteni, akkor az msdb.dbo.sysjobsteps hamar kidobta, hogy hol kell a változásokat lekövetni.
Az SSIS-szel viszont ez megszűnik.Van értelme annak, hogy a lekérdezéseket kimentem tárolt eljárásokba és csak az import-exportokat hagyom meg az SSIS számára? (Bevallom nem teszteltem még, de lehet holnap megpróbálok 2-3 jobot csinálni és megnézni, hogy mekkora a különbség.)
-
-
Louro
őstag
Sziasztok!
EGy kicsit speciálisabb kérdéssel jönnék. Adott sql server 2019. Csomagot kellene készítenem SSDT segítségével. Visual studioban a send mail nem opció, mert ahhoz su jog kellene. Így marad a Script task, ahol a system.net.mail segítségével tudnék levelet küldeni.
Ami a gondom, hogy igyekeznék hatékony kódot írni. A feladat annyi lenne, hogy van egy leválogatás. Egy hibalista az érintetteknek. Egy felhasználó egy rekordon szerepel és neki kellene levelet küldeni. Erre kurzort gondolnám a leghatékonyabbnak. De nem tudom miképp rakjam össze. Execute SQL task-ban a kurzort meg tudnám írni, de miképp "hívom meg" a script task-ban található emailküldést?
Remélem sikerült röviden összefoglalni a dilemmám
-
Louro
őstag
Sziasztok!
Bár ritkán adom fel, de ez most kifogott rajtam és a Google se segített.
Alap: SQL Server
Minta:CREATE TABLE t1 AS (id int,name varchar,dependency int);INSERT INTO t1 VALUES (1,'n1',0);INSERT INTO t1 VALUES (2,'n2',1);INSERT INTO t1 VALUES (3,'n3',1);INSERT INTO t1 VALUES (4,'n4',2);INSERT INTO t1 VALUES (5,'n5',3);INSERT INTO t1 VALUES (6,'n6',3);SELECT DISTINCT ca.idFROM t1LEFT JOIN t1 AS t2 ON t2.ID = t1.dependencyLEFT JOIN t1 AS t3 ON t3.ID = t2.dependencyCROSS APPLY (SELECT t1.ID UNION ALLSELECT t2.ID UNION ALLSELECT t3.ID ) AS c (id);A nagy kérdés, hogy én komfortosabb vagyok a JOIN-okkal, mint az APPLY-okkal. Ezt bevallom értelmezni se tudom. Az megvan, hogy egy hierarchiát épít, de a CROSS APPLY esetén a (id) kicsit fura, mert melyik ID-val köti össze a CROSS APPLY-ban lévő ID-t? Vagy duplikálna? A kód szerzője ismeretlen
Valami ilyesmi lenne?
SELECT DISTINCT ca.idFROM t1LEFT JOIN t1 AS t2 ON t2.ID = t1.dependencyLEFT JOIN t1 AS t3 ON t3.ID = t2.dependencyLEFT JOIN (SELECT t1.ID UNION ALLSELECT t2.ID UNION ALLSELECT t3.ID ) AS c ON t1.ID = c.ID OR t2.ID = c.ID OR t3.ID; -
Louro
őstag
Egy dolog kimaradt, bár ez inkább megint oldschool és úgy tudom Oracle-nyavalya, de nagyon sokan használják még, mert a veterán kollégák "így mutatták neki".
select tabla1.*
from tabla1,tabla2
where tabla1.id = tabla2.id (+)
and tabla2.id is null;Én is jobban szeretem a könnyebb olvashatóságot, azaz a
select tabla1.*
from tabla1
left join tabla2
on tabla1.id = tabla2.id
where tabla2.id is null;Amikor inner join, sokan elhagyják az inner szót. Vagy az outer is sokszor el van hagyva. Nem left outer join, hanem csak left join. Bevallom nem is tudom mit lehetne az outer helyett írni. left inner join?
nyunyu: sql server 2008-nál még biztos kötelező volt aliast használni subquery esetén is. Lehet az újabbaknál már nem, de annál biztos kellett.
-
#4673
Louro
őstag
RoyalFlush
#4664
Louro
őstag
válasz
RoyalFlush
#4664
üzenetére
Mondjuk már engem is érdekel a pontosítás. Csak egymást követőek a kérdésesek vagy a teljes tábla?
Egy példa:
Ebben az esetben
- ha csak az előzővel kell összehasonlítani, akkor a LEAD vagy LAG megoldás jó lehet. De 3. és 4. sor nem lesz hiba. Hisz növekszik a dátum.
- ha a teljes táblára kell nézni, azaz ha van olyan dátum a megelőző sorokban, ami kisebb, akkor az összes olyan sort adja vissza, akkor a Descartes szorzat a nyerő. A példában a legkisebb a 2020.01.01, így minden előtte levő hibás.Első esete szerintem azért nem lesz jó, mert ha kijön, hogy a 3. sorban lévő dátum kisebb, mint az előtte levő, azt lehet javíttatod. Majd újra futtathatod, amíg az összes sort rendbe nem teszik.
Ha nincs 2-300000 sor a tábla, lehet kitenném Excel-be a felhasználóknak és tennék rá egy feltételes formázást, =B2<B3, azaz ha kisebb a Dátum mező az előzőnél, akkor színezze ki nekik. A felhasználók többsége imádja a színeket.
-
Louro
őstag
Ezt nem is vitatom, meg lehet én is írtam ilyet. Kell a pénz. Beszállító max az elején naív, hogy minőségi terméket, szolgáltatást készíthet, de pár megrendelés után valószínűleg rájön, hogy elég olyat felvenni, ami tud valami karistolni. Nem kell, hogy elhivatott legyen. Majd kicsit feljebb tolják a projekt közben az "ajánlott gépigény" részt.
Amúgy picit ON is legyek. De nem vitaindítónak szánom, hátha kiesik valami tanulság másoknak (is).
Egyik kolléga már egy hete szenvedett valamivel. Egyszer megírta a kódot és kb. mindig ugyanazt futtatta, de 12+ óra utána megszakadt a kapcsolat (távmunka). Remélte, hogy hátha valaki más is futtat valami számításigényes feladatot és elcsíphet egy nyugodtabb időszakot.
Megnézve a kódot, kicsit átírva 38 másodpercre le lett faragva a futási idő.
Három, relatíve kicsi tábla (300e rekord) tábla lett összekapcsolva.
De a gondot az okozhatta, hogy az ON feltétel után olyan komplex feltétel volt, hogy ledobtam az ékszíjat. Valami ilyesmi lehetett:SELECT fejléc
FROM tábla1
INNER JOIN tábla2
ON (
tábla1.oszlop1 LIKE '%valami%'
OR
tábla1.oszlop2 >= tábla2.oszlop1
OR
(tábla1.oszlop3 IN (SELECT tábla3.oszlop1
FROM tábla3
WHERE oszlop2 > tábla2.oszlop4)
AND .....))Igazából annyit módosítottam a kiraktam a feltételeket külön oszlopokba CASE WHEN-ekkel, majd utána végeztem el a kötéseket. Táblakötésbe LIKE és ennyi feltétel a korábbi tapasztalataim alapján nem túl hatékony. Bár query plan-t a kollégák nem szokták nézni, pedig sokszor hasznos lenne.
+1: Sajnos sokszor látok olyat is, hogy fejlécben van tábla úgy bekötve, hogy ott is van még egy tábla a SUBSELECT-en belül. Például
SELECT
(SELECT oszlop1 FROM tábla2 WHERE tábla2.oszlop2 = (SELECT MAX(oszlop2) FROM tábla2)) c
FROM tábla1 -
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.
-
Louro
őstag
válasz
OldBoyDev
#4610
üzenetére
SELECT
Project.ProjectName AS 'Project Name',
cost.CostCategory1 AS 'Cost category1',
cost.CostCategory2 AS 'Cost category2'
FROM Project
INNER JOIN ProjectCost
ON Project.projectID = ProjectCost.projectIDHa egy projektnek több költsége is lehet, akkor....
SELECT
Project.ProjectName AS 'Project Name',
SUM(cost.CostCategory1) AS 'Cost category1',
SUM(cost.CostCategory2) AS 'Cost category2'
FROM Project
INNER JOIN ProjectCost
ON Project.projectID = ProjectCost.projectID
GROUP BY
Project.ProjectName -
Louro
őstag
Kicsit olyan ez, hogy mindkettő jó a feladatok nagy részére (, gondolok itt arra, hogy a rollup-ra pl. egy kezemen meg tudom számolni, hogy mennyiszer volt szükségem). De pl. a senior analyst kollégával nem bírom megérttetni, hogy miért felesleges Excel-ben pivotálni, miért nem bízza az erősebb SQL szerverre. Persze elbírja az Excel, csak kicsit lassabb és a felhasználói élmény csorbul.
Úgy látom bőven van mit tanulnom még. De ez jó, mert izgalmas terület
-
Louro
őstag
válasz
martonx
#4596
üzenetére
Köszönöm. Nekem is ez a legizgalmasabb a jelenlegi munkámban, bár többnyire SQL-ben oldom meg. Persze a vizualizáció Excel-ben történik - sajnos.
Esetleg tudsz mondani egy példát, hogy mi az, amit SQL-ben nem lehet vagy rosszabbul, mint Python-ban? De érzem, hogy pont a vizualizáció lesz a kulcs
-
Louro
őstag
Most jövök a kérdéseimmel
A képzések kapcsán végül a felhő alapú BI-t kezdtem el a M$ oldalán.De párhuzamosan Python-t is.
Ezutóbbival kapcsolatban lenne egy olyan kérdésem, hogy mi lehet a Python mellett erős érv, amivel meg lehetne indokolni, hogy "kell a Python a gépekre"? Este a Stackoverflow-t olvasgatva nem nagyon találtam érvet a Python mellett. Értem, hogy az egyik egy lekérdező nyelv, másik pedig programozási. De mégis rengeteg adattudós (, de csúnya így magyarul) használ Python-t. Csak még nem látom hol jön a képbe. Aggregáció során SQL nyert. ETL során az adatok manipulálását SQL-ben is el tudnám végezni.
Elnézést, ha láma kérdés, de inkább kérdezek. (Tanulnom kell valamit, mert már pár éve csak toporgok az SQL-ben és nem hinném, hogy 20 év múlva is piacképes maradnék csak SQL-lel.)
-
Louro
őstag
Bár multi, de a smucig fajta. Inkább önerőből oldom meg. A VBA-t és az SQL-t is autodidakta módon tanultam meg. De úgy érzem eljutottam arra a szintre, hogy ezt nem oldom meg önerőből.
Ahogy este olvasgattam, az SQL Server képzések szimpatikusabbnak tűnnek. Persze oda is kell más alapozó ismeret.
Eddig csak bőszen írtam az SQL-eket és próbáltam figyelni a performanciára.
-
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ő?
-
Louro
őstag
Abszolút jogos a kérdés, mert van kollégám, aki senior elemző és a left join-t és a right join-t nem ésszel használja. Nem érti a különbséget. (Amúgy a bérsáv miatt lett senior :/ )
Ha nem adatbázis beállítása a kérdés, hanem egy lekérdezés, akkor szerintem sokan tudunk itt segíteni.
-
Louro
őstag
[Személyes vélemény on]
Ez témába nem vág, csak a kérdésre válasz
:
A feladatok el vannak látva. Még plusz is. Többieknek segítek. Megosztom az infót és a társosztályoknak is segítek, amitől az osztály reputációja is nő. A fennmaradó időben próbálom javítani a rendszerünket, spórolni erőforrásokat. Amikor a jelenlegi helyemre kerültem, annyira nem volt kapacitás, hogy folyamatosan jobokkal dolgozott az adatbázisszerver. Volt, ami több, mint 3 órát futott. Kis átírással 10 perc alatt lefutott. (Több nagy tábla összekötve egy lekérdezésben, indexek nélkül. Ezeket szedtem szét több kisebb lépésre.)A fejeseknek az a fontos, hogy az ő felettük állók igényei ki legyenek szolgálva és persze mindenki fel akar valamit mutatni, de azzal nem foglalkozik, hogy a meglévő rendszerrel faragjon, mert túl kocka terület. Sajnos ilyennek miatt olyanok a nagyobb cégek rendszerei, amilyenek. Szívás minden fejlesztés.
[Személyes vélemény off]
-
Louro
őstag
válasz
martonx
#4496
üzenetére
Én a DBA-ra nem haragszok, mert lehet rá számítani, csak sajnos más feladatokat is ellát. (Munkaszervezésbeli hiba az IT részlegen (szerintem).)
Én egy kicsit IT vénával megáldottüzleti elemző vagyok. Nem csak megírom a SELECT-et, hanem a teljesítményre és az olvashatóságra is igyekszek figyelni. De amúgy értem amire utalsz.
@nyunyu (4497): Elvileg a 2008->2012 átállás már jóvá lett hagyva és jönne az UAT, de se neki nincs erre ideje, se nálunk, mert persze ez nem fontos a fejeseknek. Tesztelés nélkül biztos nem engedném. Az nagyon amatőr lenne. A jelenlegi helyzetben meg a VPN döcög. Amúgyis nehezebben halad a munka
-
Louro
őstag
válasz
formupest
#4494
üzenetére
Szia,
ha jól értem lesz két tábla. A kettő között a kapcsolatot a "gyógyszerkészítmény" fogja adni.
Egyik táblában az összetételek lesznek. Feltételezem soronként. Kicsit furcsa lenne olyan struktúra, hogy összetétel1, összetétel2, összetétel3,.... .
Másik táblában a tulajdonságok lesznek. Feltételezem itt is soronként lesznek felsorolva a hatások.Ha a számomra "furcsa" megoldás van, akkor simán JOIN-nal összeköthetőek. Ugyanaz, mint a VLOOKUP az Excelben
A másik megoldás esetén simán mellé tenni, LEFT JOIN-nal nem érdemes, mert összes lehetséges párosítást adná vissza, ami biztos nem jó. PIVOT kicsit macera kezdőként.
Én személy szerint soronként tárolnám mindkét táblát. Az összetevőket és a tulajdonságokat is katalogizálnám. Azaz bevezetnék egy táblát, amiben egyes adatok kapnának egy azonosítót és a két táblában csak az azonosítókat kellene eltárolni. Később lehet meghálálja a rendszer és a tárhely. Például a penicilin szót eltárolni 9 karakter, de ha ez a 17-es kódú összetevő, akkor ez egy sokkal kisebb helyet igénylő adat.Példa:
1-es azonosítójú gyógyszerkészítmény eseténElső tábla
1 - összetevő: por
1 - összetevő: víz
1 - összetevő: penicilinMásik tábla:
1 - tulajdonság: Fejfájás
1 - tulajdonság: HányingerHa ezt kötöd össze, akkor ilyet kapnál:
1 - összetevő: por - tulajdonság: Fejfájás
1 - összetevő: víz - tulajdonság: Fejfájás
1 - összetevő: penicilin - tulajdonság: Fejfájás
1 - összetevő: por - tulajdonság: Hányinger
1 - összetevő: víz - tulajdonság: Hányinger
1 - összetevő: penicilin - tulajdonság: HányingerNa ez jó hosszú lett. Jó lenne ismerni a kiindulási alapot. Akár fake adatokkal összedobsz egyet a Google Drive-on, talán könnyebb lenne a megoldást megtalálni.
-
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.
-
Louro
őstag
Nem saját termékről van szó, hanem egy dobozos termékről, ami kötöttségekkel jár. Ezért az SQL server is. Rendelkezésre áll a SAS is, de arra átállni (backup esetén) meg idő lenne, amire persze nem szánnak időt. Rengeteg idő lenne a meglévő jobokat átírni
Én sok kis lépéssel próbálok javítani. Igazából szorgalmiként, mert mellette ott vannak a feladataim is :/
-
Louro
őstag
Amire nekünk kell, arra jó a T-1 napi adat. Így is csoda, hogy él a rendszer. Napközben nem nyüstöljük az éles rendszert. Én próbálkozok, hogy nyerjek egy kis erőforrást, mert amikor átvettem, akkor borzasztóan rosszul megírt szkriptek futottak ütemezetten
A következő kérdés lehetne, hogy a változásokat azonosítsuk. A rendszer olyan, hogy frissít több mezőbe szinte folyamatosan. Bár jogos, hogy azzal tudnánk nyerni, de a régi adatok beazonosítása, törlése, majd áttöltése lehet időigényesebb lenne.
-
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!
-
Louro
őstag
Több 20gb+ tábla is van az átmásolandók között, ami emiatt több órát igényel. Szimplán csak át kell másolni a tábla teljes tartalmát. (Az oka, hogy ne az éles környezetet terheljük elemzési célból, hanem egy másolatot. Egy kartéziánus szorzat és megfektetjük az élest és hamar tartós szabadságra küldenek
. )Lassúnak nem biztos, hogy lassú, de ha egy kicsit is tudok spórolni, akkor én hajlamos vagyok időt tenni bele. Kicsit kattanásom, hogy ha lehet jobban, akkor miért ne.
Az SQL replikációról megkérdezem a DBA-nkat. Én ezt nem használtam. Ennek is kicsit utánajárok
-
Louro
őstag
Sziasztok!
Adott két SQL Server 2008 R2. A kettő össze van kapcsolva (Linked Server). Az lenne a kérdésem, hogy ha a két szerver között akarok olyat, hogy A szerverről másolja át a táblákat napi szinten a B szerverre, mint egy backup, akkor melyik a gyorsabb a megoldás? T-SQL vagy a SSIS?
Jelenleg az előbbi van alkalmazásban, de ha tudok időt nyerni, akkor annak örülnék. Rengeteget gugliztam már a témában, de sajna nem találtam egyértelmű választ.
Köszi előre is a válaszokat!
-
#4298
Louro
őstag
dellfanboy
#4297
Louro
őstag
válasz
dellfanboy
#4297
üzenetére
Valamilyen SQL megoldást nem támogatna a munkáltatód? Eleve 3 000 000 sorról beszélünk nagyjából. Access is elbírná, de hosszú távon lehet jobb lenne egy tartósabb megoldás.
Na meg rádobtok egy Tableau-t vagy PowerBI-t és nagyon csinos tud lenni
Az SQL, ha még nagyon új, akkor sqlzoo.net alapokra szerintem az egyik legjobb.
Access nekem a folyamatos Compact miatt volt nyűg, mert mindig nagyra hízott.
-
Louro
őstag
Ha HH:MI:SS kell, akkor
SELECT CONVERT(CHAR,CONVERT(DATETIME,AVG(CONVERT(FLOAT,t))),108)
FROM BASEIdőt előbb FLOAT-ba alakítod, majd átlagolod. A számot utána dátummá visszakonvertálod és abból kiszeded az időpontot. Ha csak óra és perc kell, akkor CHAR(5)
Oracle után szinte falnak szaladtam ennyi konvertálás láttán. M$ eléggé köti az ebet a karóhoz az adattípusaival.
-
Louro
őstag
válasz
Petya25
#4216
üzenetére
Szia,
egy minta....bár ezért nem csípem az MSSQL-t....tengernyi sok CONVERT kell sokszor.
;WITH base AS (
SELECT GETDATE()-10 t
UNION
SELECT GETDATE()-8
UNION
SELECT GETDATE()
)
SELECT CONVERT(DATETIME,AVG(CONVERT(FLOAT,t)))
FROM BASESzóval először FLOAT-ba alakítod, majd a kapott átlagot visszaalakítod dátummá.Remélem tudtam segíteni.
-
Louro
őstag
válasz
RedHarlow
#4205
üzenetére
Hogy konkrétabb legyek (TSQL megoldás):
IF DAY(GETDATE()) = 1
BEGIN
--Leválogatás kitétele
EXEC master.dbo.xp_cmdshell 'sqlcmd -S "SERVERNAME" -d ADATBÁZISNÉV -E -o "C:\Windows\System32\passwords.txt" -Q "SELECT * FROM table" -W -w 999 -s";" '--Emailküldés
DECLARE @HTML VARCHAR(2000);SET @HTML = 'Ide azt pakolsz, amit szeretnél' ;
EXEC msdb.dbo.sp_send_dbmail
@recipients = 'címzett@itcafe.hu',
@subject = 'Tárgy',
@file_attachments = N'C:\Windows\System32\passwords.txt',
@body = @HTML,
@body_format = 'HTML';
ENDBeteheted napi futásba is, nem fogja elvinni az erőforrást. Vagy kihagyod az IF-es részt és a Schedule részben megadod, hogy minden hónap első napján fusson le.
Persze igényesebb megoldás lenne SSIS Package-be tenni. De feladat méretétől függ. Az apró lekérdezéseket inkább így oldom meg.
-
Louro
őstag
válasz
RedHarlow
#4205
üzenetére
Környezet? Oracle, SSMS, .... ? Ez eléggé függ attól.
Röviden azt mondanám általánosságban, hogy legyen egy IF elágazás, ahol megmondod, hogy az aktuális nap a hónap első napja, akkor fusson el, különben ugorja át. Majd ezt az egészet egy package-be
Én TSQL-lel is pakolok olykor ki, bár tudom, hogy nagyon retro és inkább SSIS kellene, de lusta vagyok egy exportra package-et készíteni
-
Louro
őstag
válasz
martonx
#4200
üzenetére
Gondolom nálatok is egy interjún, egy szimpla SELECT feladat láttán, ha azt kérné a jelentkező, hogy szóban elmondhatja e, hogy hogyan oldaná meg, ti is elkerekedett szemekkel kérnétek, hogy mondja. (Egy adatelemző ne beszéljen, kódoljon és értelmezzen
)Előző munkahelyemen Oracle volt és ott a temptáblát a többsége simán CREATE TABLE-DROP megoldással kezelte. (Mondjuk én CTE-párti vagyok, de sok kifinomult megoldás van a szemét elkerülésére.)
-
Louro
őstag
válasz
bambano
#4197
üzenetére
A HAVING-et általában subselect-tel oldják meg az emberek. Az első kettő az nagyon alap. A 3. feladatnál csak arra voltam kíváncsi, hogy kétségbeesik vagy nem. HAVING simán helyettesíthető. Csak azzal elengánsabb.
Már a 2. olyan kolléga van mellettem, akik több év elemzés után nálunk találkozott a ROW_NUMBER()-rel. Én meg amikor autodidakta módon tanultam, annyira alapnak véltem.
De az se mindegy, hogy mennyi tábla van összekötve. Előző osztályvezetőnk olyan kódot írt, amiben legalább 15 tábla volt LEFT JOIN-nal összekötve. (MSSQL.) Tetű lassú volt. 4-4,5 órát futott. Azzal, hogy szétszedtem 4 részre, 20-30 perc alatt megvolt az eredmény. Semmi mást nem néztem, de van egy olyan érzésem, hogy lehetne performanciát javítani.
Itt arra akarok utalni, hogy nem elég, hogy valaki ismeri a főbb parancsokat, igényesnek is kell lenni és gondolni kell arra, hogy limitált az erőforrás. (A rengeteg temptábláról nem is beszélve. Egy hónapig takarítottam, a GDPR bevezetése előtt.)
Speciális dologkra interjún nem is kérdeztem, mert úgyis ott a gugli. Én is használom, ha elakadok vagy keresek gyorsabb, jobb megoldásokat. Hülyeségnek tartottam mindig, ha interjún valaki nagyon mély ismeretre kérdezz. A jelentkező is lehet tudna olyat kérdezni, amit meg az interjúztató nem tudna :/
-
Louro
őstag
válasz
Nicotin
#4191
üzenetére
Szia,
mi nemrég kerestünk embert, akinek egy SELECT, egy JOIN és egy HAVING feladat volt. Kb. 20-ból 1 ment át. Már ennek is örültünk és fel is vettük
De nem is ez a lényeg. Volt olyan, nem is egy, aki emberileg jónak tűnt. Nekik felajánlottam, hogy tolják le az sqlzoo.net oldalt. 2 hét múlva hívja fel a HR-est és beszéljünk újra. Egyik se volt elég motivált, hogy visszatelefonáljon. Pedig az az oldal nagyon jó az alapokra. Volt egy diákunk, aki üresjárataiban 1,5-2 hét alatt kitolta és tudatosan használta. Ha meg elakadsz, a másik programozói tudást tudod fejleszteni, azaz guglizni kell. Rengeteg fórumon mutatnak megoldást. De azért 5 perc után nem érdemes rákeresni
Igaz ez a standard SQL, nem MySQL, de az alap menjen. Ha az alap betonstabil, akkor azzal is megoldod a legtöbb feladatot.
Kísérletezéshez a W3Shools.com/sql se rossz.
-
Louro
őstag
Sziasztok!
Adott egy SMSS 2008 R2 és egy VS 2008.
VS-ban elkészítenénk a package-et. A package dolga annyi lenne, hogy megfog egy .xls (nem .xlsx) fájlt és azt be kellene töltenie táblába.VS-ban futtatva simán végrehajtódnak a lépések.
Ahogy job-ot készítenénk rá SMSS-ben, elhasal a dolog. A netet feltúrva már átállítottuk 32 bitesre a job-ot.
Nektek esetleg ötlet, javaslat? .csv-t is próbáltuk. Azzal is hasonló. Kicsit más, de hasonló.
A hibaüzenet:
Executed as user: xxxxxxxxxx. Microsoft (R) SQL Server Execute Package Utility Version 10.50.6000.34 for 64-bit Copyright (C) Microsoft Corporation 2010. All rights reserved. Started: 9:03:32 AM Error: 2017-06-13 09:03:34.35 Code: 0xC00F9304 Source: filename Connection manager "Excel Connection Manager" Description: SSIS Error Code DTS_E_OLEDB_EXCEL_NOT_SUPPORTED: The Excel Connection Manager is not supported in the 64-bit version of SSIS, as no OLE DB provider is available. End Error Error: 2017-06-13 09:03:34.36 Code: 0xC020801C Source: filename_import 1 Excel Source [77] Description: SSIS Error Code DTS_E_CANNOTACQUIRECONNECTIONFROMCONNECTIONMANAGER. The AcquireConnection method call to the connection manager "Excel Connection Manager" failed with error code 0xC00F9304. There may be error messages posted before this with more information on why the AcquireConnection method call failed. End Error Error: 2017-06-13 09:03:34.37 Code: 0xC0047017 Source: filename_import 1 SSIS.Pipeline Description: component "Excel Source" (77) failed validation and returned error code 0xC020801C. End Error Error: 2017-06-13 09:03:34.37 Code: 0xC004700C Source: filename_import 1 SSIS.Pipeline Description: One or more component failed validation. End Error Error: 2017-06-13 09:03:34.37 Code: 0xC0024107 Source: filename_import 1 Description: There were errors during task validation. End Error DTExec: The package execution returned DTSER_FAILURE (1). Started: 9:03:32 AM Finished: 9:03:34 AM Elapsed: 1.888 seconds. The package execution failed. The step failed. -
#3133
Louro
őstag
Apollo17hu
#3132
Louro
őstag
válasz
Apollo17hu
#3132
üzenetére
Az a THEN 1, azért problémás és igyekeztem röviden megúszni a kódsort. A THEN után is még 10 sor legalább, amiből az eredmény származik. Megoldhatnám, hogy lekezelek külön mindent, de akkor a THEN utáni részt kellene sokszor bemásolni.
-
Louro
őstag
Sziasztok!
Olyan lehet case-ben vizsgálni, hogy
case when 1=1 and 2=2 and 3=3 and
case when 4=4 and 5=5 then 'true' else 'false' end then 'jó' else 'nem jó' endHasonló vizsgálatot kellene végeznem, de nem találtam sehol se megoldást rá.
Lehetne rengeteg egymásban ágyazott case-zel megoldani, de reméltem, hogy pár sorban ezt letudom.
Nektek van egyéb ötletetek?
-
Louro
őstag
Szia,
powershell elindul. Régen még tanultam is. Megpróbálom elsőként abban megoldani.
Nem ragaszkodok a Windows saját ütemezőjéhez, de mivel nem vagyok admin, nem vagyok DBA, így korlátozottak a lehetőségeim. A DBMS Scheduler-ért küzdünk, de az nem 100%, hogy meglesz. Így a meglévő eszközökhöz nyúlnék.
-
Louro
őstag
Sziasztok!
Lehet elég bagatel kérdést fogok feltenni, de hátha van rá megoldás. (Vagyis van, mert Excel makróval meg tudom oldani.)
Adott egy .sql fájl. Benne rengeteg trigger (insert, update, temptáblák létrehozása,...). Van arra lehetőség DBMS Scheduler nélkül valahogy beütemezni?
Környezet: Oracle
Elérhető programok: Toad és PL SQL Dev 9Windows ütemező nem tudom milyen nyelvet igényel, de lehet van mégegyszerűbb megoldásotok is. Az Excel makróval az a gondom, hogy akkor az Excelt teljesen kilövöm a gépen, ha fut.
Válaszotok előre is köszönöm.
-
Louro
őstag
válasz
martonx
#3060
üzenetére
Sziasztok,
@Apollo17hu : Köszönöm, jónak tűnik. Ma meglesem.
fiddle-t még nem használtam SQL-re, csak JAVA-s időkben.
De ez lenne a kód:
CREATE TABLE rendeles_db (
azon varchar2(10),
db number
);INSERT INTO rendeles ('K',1); --Első K rendelés
INSERT INTO rendeles ('K',2); --Második K rendelés
INSERT INTO rendeles ('L',1); --Első L rendelés
INSERT INTO rendeles ('M',1); --Első M rendelés
INSERT INTO rendeles ('L',2); --Második L rendelés
INSERT INTO rendeles ('K',3); --Harmadik K rendelés
COMMIT;CREATE TABLE rendeles_q (
azon varchar2(10),
rendeles_db number
);
--Itt a rendelésekhez tartozó darabszámot adjuk meg.
--A rendelésekhez pedig meg kellene mondani, hogy hányadik a hónapban.
INSERT INTO rendeles_q ('K',5);
INSERT INTO rendeles_q ('K',4);
INSERT INTO rendeles_q ('M',8);
INSERT INTO rendeles_q ('K',2);--Elvárt az lenne ne kézzel kelljen sorszámot adni a rendelésnek, hanem gép adja.
--Így nézne ki a temptábla, amit kapcsolótáblaként használnék fel:
--K,4
--K,5
--M,2
--K,6--Ha ez meglenne, akkor a rendelésekhez mellé tudnám tenni, hogy hányadik a hónapban.
--A rendeléshez az azonosító egyik eleme a sorszám.Köszönöm,
Csabi -
Louro
őstag
válasz
martonx
#3058
üzenetére
Megpróbálom leírni a lényeget.
Adott az első alaptábla. Ezek rendelések. Három kategória a K, L, M.
Két oszlopa van. Azon és DB
Legyen a tartalma:
K1 - 5
L1 - 3
M1 - 12
K2 - 8
M2 -10
K3 - 7Az lenne a cél, hogy egy másik táblában mellé tegyem, hogy hányadik rendelés a hónapban kategóriánként.. Van egy tábla, ahol gyűlnek a sorszámok.
K-ból már 3, L-ből 2, M-ből pedig 5 rögzített sorszám van.
Az elvárt az lenne az új táblában, hogy
K1 - 4
K2 - 5
K3 - 6
L1 - 3
M1 - 6
M2 - 7Remélem így kerekebb.
-
Louro
őstag
Igazából az a feladat, hogy van egy tábla, amiben van x darab rekord. Ez folyamatosan változik. A rekordokat 3 részre kell megadott feltételek mentén bontani.
Az új táblában pedig
- 3 kategória alapján megszámolni mennyi rekord van az első táblában.
- majd mindegyikhez növekvő sorszámot társítani.Ezt most úgy csináltam meg - és lefutott - kivettem a 3 kategória darabszámát az első táblából. Majd 3 ciklussal mellé tettem a növekvő sorszámot.
SQL-lel még kategóriánként meg tudom számoltatni, hogy melyikhez mennyi tartozik, de a növekvő sorszámot már nem. Mondanám, hogy 3 temp tábla, de akkor extra táblákat kellene létrehozni.SQL ismeretem kicsit jobb, mint kezdő, de messze nem merész amatőr.
-
Louro
őstag
Sziaszotk!
Adott a PL SQL.
Performancia vagy stabilitási gondot okozhat ha egy normál script közé beszúrok egy procedurát? Vagy le se futna? Procedurával még csak most ismerkedek. De elsőre úgy érzem a VB tapasztalat segíthet.
Pl.:
select * from táblanév;update....;
create table táblanév2 as select * from táblanév3;
begin
declare
end;select count(8) from táblanév2;
select count(8), count(distinct oszlopnév) from táblanév3; -
#2942
Louro
őstag
Apollo17hu
#2941
Louro
őstag
válasz
Apollo17hu
#2941
üzenetére
+1 erre. Én is ezzel a kettővel darabolnék, ha van egyértelmű szeparátor. Ha pedig fix hosszúságúak az azonosítók, akkor még könnyebb a dolgod. Akkor csak SUBSTR() kell.
-
Louro
őstag
válasz
rum-cajsz
#2722
üzenetére
Szia,
decode-dal még nem néztem, de jó ötlet. Oracle az alap, de valamiért case esetén kiesnek az érintett sorok.
Decode-dal is megnéztem és úgyis csak kiejtette a találatokat.
A kód:
select id,name from somewhere
where 1=1
and decode (id, '1','A',
'2','B',
'3','C',
id) = idNem vagyok öregmotoros. Igyekszek a kérdéseim előtt azért utánanézni, szóval, ha kihagytam egy vesszőt, nem haragszok meg a segítségért
-
Louro
őstag
Sziasztok!
Van arra lehetőség, hogy egy-egy találatot átnevezzek. Pl:
select * from somewhere
where 1=1
and 1st_IDX = case 1st_IDX when '1' then 'A' when '2' then 'B' when '3' then 'C' endNagyvonalakban ez lenne a kód. De sajnos inkább meg sem jeleníti a találatok ahol a 1st_IDX 1,2 vagy 3. (A példánál maradva.)
Segítségeket előre is köszönm!
-
Louro
őstag
Sziasztok!
A VB után most a PL/SQL Dev-vel ismerkedek. Itt van lehetőség arra, hogy például egy megadott mappából vegye az összes .csv kiterjesztésű fájlt, majd azokból csak bizonyos mezőket hozzak el és ezen felül a fájlnevet betöltsem egy mezőbe?
VB szkripttel ezt megoldottam, de itt nem találok a neten rá vonatkozó cikket.
Segítségetek előre is köszönöm!
(Max jönnek az okosabbak és mutatnak jobb megoldást. Munka után, agymosottan ezt tudtam segíteni.)
Engem is bosszantott, amikor volt verzióváltás. 
Új hozzászólás Aktív témák
- HiFi műszaki szemmel - sztereó hangrendszerek
- Milyen egeret válasszak?
- Nintendo Switch 2
- gban: Ingyen kellene, de tegnapra
- Kormányok / autós szimulátorok topikja
- Android alkalmazások - szoftver kibeszélő topik
- PlayStation 4
- Exkluzív órák
- Vicces képek
- Xiaomi 15T Pro - a téma nincs lezárva
- További aktív témák...
- Új, Aktiválatlan iPhone 16 (128 GB) (rendelhető)
- ÁRGARANCIA! Épített KomPhone Ultra 7 265KF 32/64GB RAM RX 9070 16GB GAMER PC termékbeszámítással
- Samsung Galaxy S22 Ultra 5G 256GB, Kártyafüggetlen, 1 Év Garanciával
- Mini Pc HP ProDesk 600 G2 G3 G4 /// 6-8. gen //// i3 / i5 /// garancia /// Budapest / MPL / Foxpost
- Lenovo ThinkPad // T - Széria // X1 carbon // X1 Yoga 2-in-1 // és a többiek... 3-12. gen.
Állásajánlatok
Cég: Laptopszaki Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest