Új hozzászólás Aktív témák
-
martonx
veterán
válasz
zolynet
#1395
üzenetére
Egyébként bármilyen csúnya is SQL-ben ilyet használni, de egy While ciklus szerintem erre pont megfelel.
Második sortól kezdve végiglépdelsz rajta, mindig kiveszed az eggyel előző számot, és azt hozzáadod egy 0-ról induló változóhoz.
És továbbra sincs ebben semmi rekurzió. -
zolynet
veterán
Sziasztok!
Segítséget kérnék mert rekurzívban nem vagyok otthon.
1
2
3
4
5
6
7
8
9
10
Legyen adott ez az egyszerű táblázat, ebből kellene nekem egy ilyet csinálni:
1 1
2 3
3 6
4 10
5 15
6 21
7 28
8 36
9 45
10 55
Azaz az oszlop első két számát (nem id, csak egyszerű példát akartam) összeadom, ez összegét az oszlop következő számával adom össze, majd ennek az összegét a következővel és így tovább.
Aki vágja a rekurzívat annak kisujjból. Én egyszer írtam életem során egyet, egyszerű volt de megizzadtam vele, ez a része nem megy sajnos.
T-SQL nyelven kellene.Üdv
ZoL -
martonx
veterán
Szerintem erre nincsen igazán jó szakirodalom. Esetfüggő, hogy mikor mennyire érdemes normálformára hozni, milyen táblastruktúrát érdemes létrehozni, mennyire kell teletömni indexekkel egy-egy táblát stb...
Egy-két SQL optimalizálás problematika elég szokott lenni, hogy felnyissa az ember szemét a DB tervezés alapjaira.
Nagyon általánosságban beszélve: 1. - 2. normálforma elég szokott lenni. Láttam olyan DB-t, ahol még az Igen/Nem is normalizálva volt külön paraméter táblába. Nos, ez már a ló túlsó oldalára átesés.
Ugyanez a helyzet az indexelésekkel. Egy bizonyos szintig nagyon jó, hogy van mindenféle joinokban használt index-ed. Aztán mikor már mindenen index figyel és szegény db motor egy-egy insertnél nem győzi az indextáblákat frissíteni, akkor ez már kontraproduktív.
Nagyon nincs, és nem is lehet általános érvényű tanácsot adni SQL adatbázis tervezéshez. -
Lacces
őstag
Mivel olyan jól sikerült a JOIN-os témámmal berobbani MySql topicba, így jönne ide kérdésem.
Megbízható szakirodalmat, online anyagot tudnátok ajánlani adatbázis tervezéshez? (Mivel úgy nézz ki, hogy meló helyen nem tudok kitől kérdezni, így egyedül próbálnék belejönni)
Igényem lett, a profizmusra. -
lakisoft
veterán
Sziasztok,
Aki hasonló témában dolgozik várom szeretettel:
MSSQL, SQLSERVER, T-SQL, SYBASE adatbázisfejlesztők, DBA-k, üzemeltetők ide -
válasz
martonx
#1386
üzenetére
Igazából az Express beállíta magának alapból egy Instance nevet (nem hagyja defaulton). Nagy cégeknél meg azárt nem használják az instance nevet (vagy inkább nem szokták) - mert álatlában az a policy, hogy egy szerveren egynél több DB instance nem lehet. Inkább virtualizálnak.
-
bpx
őstag
válasz
lakisoft
#1383
üzenetére
"Sokan tudják, hogy az SQL Serverből több példányt (azaz instance-ot) is lehet telepíteni ugyanarra az operációs rendszerre. ...
Az instance-ok közül legfeljebb egy lehet az úgynevezett default instance, a többi named instance kell hogy legyen. A default instance-nak nincs külön neve, azaz ő a futtató host nevével megegyező nevet visel, az SQL1 szerveren a default instance neve SQL1 lesz. A named instance-ok a host neve után backslash-sel elválasztva viselik a nevüket: SQL1\WEB, SQL1\TESZT stb. " -
martonx
veterán
válasz
lakisoft
#1385
üzenetére
Úgy mondanám, hogy Expressnél biztosan kell instance a szerver névhez.
Enterprise verziónál, ha ugyanazon db szerveren nem fut több különböző instance, akkor elvileg nincs is külön instance jelölés. Kivéve, ha a DB admin direkt úgy állította be, hogy akkor is legyen.
De nem vagyok DB admin, így nem vagyok 100%-kig biztos ez utóbbiban. -
-
lakisoft
veterán
válasz
martonx
#1380
üzenetére
Van a gépemen.
Microsoft Windows [verziószám: 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. Minden jog fenntartva.
C:\>bcp
usage: bcp {dbtable | query} {in | out | queryout | format} datafile
[-m maxerrors] [-f formatfile] [-e errfile]
[-F firstrow] [-L lastrow] [-b batchsize]
[-n native type] [-c character type] [-w wide character type]
[-N keep non-text native] [-V file format version] [-q quoted identifier]
[-C code page specifier] [-t field terminator] [-r row terminator]
[-i inputfile] [-o outfile] [-a packetsize]
[-S server name] [-U username] [-P password]
[-T trusted connection] [-v version] [-R regional enable]
[-k keep null values] [-E keep identity values]
[-h "load hints"] [-x generate xml format file]
C:\>bcp help
usage: bcp {dbtable | query} {in | out | queryout | format} datafile
[-m maxerrors] [-f formatfile] [-e errfile]
[-F firstrow] [-L lastrow] [-b batchsize]
[-n native type] [-c character type] [-w wide character type]
[-N keep non-text native] [-V file format version] [-q quoted identifier]
[-C code page specifier] [-t field terminator] [-r row terminator]
[-i inputfile] [-o outfile] [-a packetsize]
[-S server name] [-U username] [-P password]
[-T trusted connection] [-v version] [-R regional enable]
[-k keep null values] [-E keep identity values]
[-h "load hints"] [-x generate xml format file]
C:\> -
lakisoft
veterán
Sziasztok,
SQL serveres kérdésem lenne:
bcp-vel hogyan lehet kapcsolódni lokális SQL serverhez?
A lényeg hogy szükségem van az összes tábla *fmt formátum fájljára.Egy hasonló importhoz kellene a text szétparzolását segítő formátum file. Ezt szererném legenerálni a céltábla (pubs..authors2 ) segítségével
BULK INSERT pubs..authors2 FROM 'c:\new_auth.dat'
WITH (FORMATFILE = 'c:\authors.fmt') -
#1378
martonx
veterán
Apollo17hu
#1377
martonx
veterán
válasz
Apollo17hu
#1377
üzenetére
Segítek. Next - next - finish. Közben mindent default-on hagysz. Nem bonyolult ez.
-
#1377
Apollo17hu
őstag
martonx
#1376
Apollo17hu
őstag
válasz
martonx
#1376
üzenetére
Nincs meg az elméletem hozzá, csak lekérdezéseket írogattunk, arról szinte semmit nem tudok, hogy mi a teendő a MySQL szerver telepítésekor, és hogy mire kell figyelni, milyen kapcsolatokat kell beállítani telepítéskor stb. Erről is szükségem lenne egy emészthető leírásra, ha akad.
-
#1376
martonx
veterán
Apollo17hu
#1375
martonx
veterán
válasz
Apollo17hu
#1375
üzenetére
ez most komoly kérdés volt?
Például a Dreamcoder for MySQL-hez na vajon mi kell? Segítek kell egy Dreamcoder, meg egy MySQL.
Töltsd le őket, és hajrá
-
#1375
Apollo17hu
őstag
Apollo17hu
őstag
Sziasztok!
Egyetemen az ingyenes SQL Developert használtuk adatbázis-kezeléshez. Szeretnék itthon is kisebb adatbázisokat létrehozni, a Developer segítségével pedig SQL-kódok formájában lekérdezéseket írni.
Mi szükséges ahhoz, hogy a PC-men mindezt meg tudjam valósítani (ingyen)? Van-e esetleg egyszerűbb/kezelhetőbb megoldás az otthoni adatbázis-kezelésre?
A hangsúly az SQL-lekérdezéseken van, nem kedvelem az Access-szerű varázslást...
-
#1374
martonx
veterán
Sk8erPeter
#1373
martonx
veterán
válasz
Sk8erPeter
#1373
üzenetére
Én 3 cégre látok rá, ezekből kettő az igazán nagyok között játszik (vagy legnagyobb? hm...) A harmadik is komoly tényező. Őszintén meglepődnék ha a többiek nagy részénél nem fordulna elő MS Access.
-
#1372
sztanozs
veterán
Sk8erPeter
#1371
válasz
Sk8erPeter
#1371
üzenetére
Én kettőről is (biztosan) tudok - mind a kettő benne van az első ötben a saját kategóriájában...
-
#1371
Sk8erPeter
nagyúr
martonx
#1364
Sk8erPeter
nagyúr
válasz
martonx
#1364
üzenetére
És ez szerinted jó?
Amúgy az Exceles+TXT-s+rendes adatbázisos összekattintgatós móka valóban egyszerűnek tűnik, bár ha normálisan egységesítve vannak a dolgok, akkor elvileg nem lenne szükség TXT-re és Excelre, de nem akarok naiv lenni, tudom, hogy ez soha nincs így. Tehát az a funkciója hasznos lehet.Amúgy sorolhatnál pár ilyen pénzintézetet (!), ahol az Access a fő alap, tényleg érdekelne.
-
válasz
Dave-11
#1369
üzenetére
Mennyire eltrejedt-re csak megerősíteni tudom martonix megjegyzését - miszerint bár nem elsődleges rendszerek, de korábbi felhasználói automatizálásból itt-ott igen komoly összetett alkalmazások nőttek ki Excel / Access vonalon (főleg kockázatkezelés és pénzügyi tervezés területén). Ha szerencséd van (illetve ha nincs szerencséd), akkor fogsz ilyenekkel szívni még 5 év múlva is, mire oda jutsz, hogy ilyen helyen dolgozz... De még akár foxproval is találkozhatsz.
-
#1369
Dave-11
tag
Sk8erPeter
#1362
Dave-11
tag
válasz
Sk8erPeter
#1362
üzenetére
"Egyébként felejtsd el, hogy hasznos, igazán komoly célokra nem használják."
Ezt meg tudom érteni, de érettséginél Accest kellesz használni.
Igazából csak ezért kérdeztem rá, meg hogy ez mennyire elterjedt, mert korábban én még nem is hallottam róla. -
martonx
veterán
válasz
PazsitZ
#1366
üzenetére
Az SQL tudás mindennél többet ér (bár kitudja pár év múlva a NoSQL-ek felfutásával mire lesz jó a mostani SQL tudásunk
![;]](//cdn.rios.hu/dl/s/v1.gif)
), az MS Access-ennek csak egy speciális vetülete. Az Access SQL meg különösen kilóg az SQL-ek sorából.
A fentebb hozott Access-es példámhoz egyébként SQL tudás kell. A kattitngatást nem arra értettem, hogy az Access designerével join-olod a táblákat, hanem az adatforrások Access-be behúzására. Személy szerint Access-ben is mindig kézzel írom az SQL kódot, a kód designert kb. soha nem használtam még benne.
És nehogy Access pártinak gondoljatok, csak próbáltam rávilágítani, hogy a világ nem szimplán fekete és fehér. -
PazsitZ
addikt
válasz
martonx
#1364
üzenetére
De azért abban talán megegyezhetünk, hogy többet ér az alapvető sql tudás, mint az access kattingatási tapasztalat.
Mert egy sql-es feltételezem megoldja az access-ben is a feladatot, addig fordítva már talán nem biztos, hogy ennyire triviális a dolog...
Bár lehet tévedek, bevallom, talán egy évtizede nem láttam már access-t -
martonx
veterán
Egy eset van, amikor az Access tényleg hasznos. Mindenhonnan magába tud fogadni adatokat, és ezekkel SQL szinten tudsz dolgozni.
Van pl. néhány klasszikus SQL szerveren futó táblád, meg van néhány rendszeresen frissülő TXT file-od, meg pár excel táblázatod. Ezeket SQL szerűen együtt kezelni, joinolni stb. MS Access-ben pár kattintás.
Nagyvállalati környezetben számtalan ilyen eset előfordul.
Persze meg lehet ezer más módon is oldani a fentebb vázolt problémát, de az MS Access-es megoldás a létező leggyorsabb, legegyszerűbb. -
#1364
martonx
veterán
Sk8erPeter
#1362
martonx
veterán
válasz
Sk8erPeter
#1362
üzenetére
Tudok több olyan nagy pénzintézetet mondani Magyarországon, ahol jelentős programok MS Access-ben vannak megvalósítva.
-
#1363
modder
aktív tag
Sk8erPeter
#1362
modder
aktív tag
válasz
Sk8erPeter
#1362
üzenetére
Ehhez pedig én is még annyit hozzátennék, hogy az access-t, mint platformot vagy toolt amire alkalmazást lehet írni, tényleg felejtsd el. arra viszont jó, hogy gyakorold vele az SQL-t. Ha pedig az SQL-t már nagyjából ismered, a szemlélet és a szintaxis már nem annyira különbözik az egyes relációs adatbázisoknál. persze mindig vannak bonyolultabb esetek, amikor mélyebbre kell ásnia magát az embernek egyes adatbázis gyártók megoldásaiba.
Ha pedig azt mondod, hogy gyakorolni szeretnél, arra én is inkább a MySQL-t vagy az MS SQL express-t ajánlom, mert azok legalább rendes, "production" környezetben használt adatbázisok, és ingyenesek. -
#1362
Sk8erPeter
nagyúr
Dave-11
#1361
Sk8erPeter
nagyúr
válasz
Dave-11
#1361
üzenetére
"Állítólag nagyon hasznos"
Ki szerint? És milyen célra hasznos?"ami ezt a fajta használatát mutatja be"
Melyik fajta használatát?Egyébként felejtsd el, hogy hasznos, igazán komoly célokra nem használják. Ezerszer hasznosabb, ha a MySQL-re fekszel rá (ha már amúgy is van valami előismereted), vagy MS SQL Serverre, Oracle-re, stb... na, ezek hasznosak.
-
Dave-11
tag
Az idei tanév kezdetétől fogok járni a suliba emelt infó faktra (felkészítés az érettségire), és mondta egyik haverom, hogy fogunk SQL-ben programozni a Microsoft Acces használata során, adatbáziskezelésnél.
Egy kicsit konyítok hozzá, még a PHP+MySQL -es ügyködéseimről maradt meg valami.
Állítólag nagyon hasznos, ti mit gondoltok róla?
Valami tutorialt tudtok dobni, ami ezt a fajta használatát mutatja be az Accesnek? -
#1360
Sk8erPeter
nagyúr
Lacces
#1359
Sk8erPeter
nagyúr
Akkor ezt folytatva: mindenki érti már szerintem, mit szeretnél, úgyhogy még egy ilyen csodás példa nem kell a magyarázat tisztázásához
. Előbb linkelt cucc utsó hsz.-ében leírtam, hogy OK, minden hirdető júzer, de nem minden júzer hirdető.
Tehát akkor rövidre zárva a dolgot: nem kell az a kapcsolótábla. A hirdető egyéb adataiba egyszerűen bepakolod a user id-t.Persze lehet ezt tovább bonyolítani, ha még tovább lenne bontva, hogy bizonyos hirdetőknek extra paramétereik lehetnek, és akkor megint előkerül a probléma, hogy NULL értékűek bizonyos paraméterek azoknál a hirdetőknél, amelyeknél nincsenek meg azok az extra paraméterek.
Akkor már egy táblába kéne pakolni a user id-t, paraméter id-t, paraméterhez tartozó egyik lehetséges value id-t, és így tovább... de gondolom nálad egyezne az összes hirdető plusz adata. -
Lacces
őstag
és Sk8erPeter és martonx, köszönöm a választ.
Picit tovább boncolgatom. A User_Hirdetés tábla az lett rontva névre, az valójában User_Hirdető kapcsoló tábla akart volna lenni.Ez csak egy elméleti gyakorlat... Na várj kitalálok valamit. Ez eszembe jutott és elgondolkoztam rajta.
Zsír, van egy példám
.Van egy weboldal, ahol mesehősök vannak rajta, és meg lehet rendelni az ő szolgáltatásukat.
Például.: (Ennél jobb példa nem jutott eszembe) Super Mario hirdet, mint hirdető. Én, mint oldal tulajdonos, a hirdetőtől szeretnék kérni vezeték nevet, kort, számlázási adatokat! (ezért kezelem külön, mert a sima felhasználótól ilyet nem kérek). A felhasználó, pedig tud üzenetet küldeni Super Marionak, hogy vezetéket kellene szerelni, vagy aranyat gyűjteni. Illetve tudom értékelni Super Mario hirdetését: Hogy hüm, ő egy nagyon jó vezetékszerelő.
Ahhoz hogy valaki hirdést adjon fel, az-az hirdessen, ahhoz regisztrálnia kell magát.És így a user_táblával eltudnám azt intézni, hogy ez a felhasználók beléptetéséhez kell és ennyi. És nem lenne egy csomó null, érték.
Felhasználó, tábla most is annyi adat, amennyi. Mit tud a weboldalon, csak regisztrált felhasználó tud üzenetet küldeni a hirdetőnek, esetleg kommentálni a hirdetésben látható terméket!(De egy mezei felhasználótól nem kérem, hogy adjon meg szállítási címet, keresztnevet, ezért tekintem őt, mint külön típus.). És egy nem regisztrált felhasználó nem tudja értékelni Super Mariot, meg üzit küldeni neki.
Akkor ezért szedném külön, hogy user tábla, hirdetés tábla, és hirdető_adatai tábla. (és akkor a hirdetőtáblában lenne: user_id, számlázási adatok stb.)
-
#1357
Sk8erPeter
nagyúr
Lacces
#1356
Sk8erPeter
nagyúr
modder sok mindent leírt előttem, ami a megvalósítást illeti, tehát azzal a résszel egyetértek. Viszont én még annyit tennék hozzá, hogy bennem a hsz.-ed láttán egyből az a kérdés merült fel, hogy vajon miért feltételezed, hogy a hirdető egy külön állatfaj.
A hirdető is egy regisztrált felhasználó, tehát egy user, akinek a helye a user táblában van. Tehát teljesen felesleges a "hirdető neve, hirdető kora, hirdető egyéb adatai", stb. adatokat külön táblában tartani. Ez a felhasználóhoz tartozó adat (user tábla, vagy esetleg egyéb adatok miatt ehhez kapcsolt tábla, de ez opcionális). Az már másik kérdés, hogy ez a felhasználó egyáltalán hirdethet-e, ad-e fel hirdetést, és ha igen, az adott hirdetésekhez milyen adatok tartoznak.
Itt most a hirdetés hozzákapcsolása szempontjából tehát mellékes, hogy szerepkör alapján hirdethet-e csupán a felhasználó, vagy bármilyen bejelentkezett felhasználó feladhat hirdetést. Nyilván egy expressz.hu-hoz hasonló oldalon az a fő profil, hogy bárki feladhasson hirdetést (mondjuk adott összeg befizetése után), tehát ott nem kell külön hirdető szerepkör (hacsak nem a fizetés után kapja meg a felhasználó a "hirdető" szerepkört, ami akár le is járhat, de még ezt a kérdéskört is lehetne boncolgatni).Lényeg tehát: a hirdető is egy felhasználó. A hirdetés pedig külön adat, ami - ahogy előttem elmondták - egyértelműen egy felhasználóhoz tartozik (elég ritka az az eset, hogy több embert akarsz megjelölni hirdetés feladójaként...), tehát itt nem kell külön kapcsolótábla a hirdetés-user kapcsolathoz.
-
#1356
Lacces
őstag
Sk8erPeter
#1354
Lacces
őstag
válasz
Sk8erPeter
#1354
üzenetére
jó, rosszul fogalmaztam
. Építő jellegű kritika... nem pedig, hogy ez, milyen sz***, inkább menj el vasútasnak stb... Na, halljam te hogy csinálnád -
modder
aktív tag
Ja, nem jó.
A user_hirdetés kapcsolótáblában inkább user_id és hirdetes_id-nak kellene szerepelnie.
De teljesen fölösleges is a kapcsolótábla, mivel ez egy one-to-many kapcsolat a user felől a hirdetések felé: egy user több hirdetés. így elég csak user_id-t tárolni a hirdetés táblában, mit te hirdető_id-nak nevezel. Kapcsolótáblát csak a many-to-many relációknál használnak.
... Esetleg akkor, ha a kapcsolatnak külön tulajdonságot rendelsz, ami a kapcsolatra vonatkozik. akkor viszont érdemes egy unique constraint-et tenni a kapcsolótábla hirdetés_id mezőjére, hogy elkerüld, hogy egy hirdetést véletlenül több felhasználóhoz kapcsolj
Hirdető táblában nem kell a hirdetés_id. akkor minden hirdetőhöz csak egy hirdetés tartozhatna. a hirdető<-->hirdetést megadja a hirdetés tábla hirdető_id-ja.
teljesítményben annyit tudsz javítani, hogy indexeld a keresésben használt mezőket, vagy ha egyszerre több mezőt is használsz egy-egy fajta keresésben, akkor indexet megadhatsz több mezőre is.
Ha pedig többmillió rekordod lesz meg brutál forgalom meg istentudja, akkor táblaparticionálás. ez a két legfontosabb dolog teljesítményben -
Lacces
őstag
Köszönöm a válaszokat!
Másik kérdés, inkább adatbázistervezéshez kérnék segítséget
. Webalkalmazásról van szó, felhasználó és felhasználói csoportok. (És ahogy gondolkoztam magamban, ez inkább adatbázis lenne).Az elképzelésem az, hogy vannak különböző felhasználói csoportok. De minden felhasználót 1 táblában tárolok, és aki hirdető, vagy tag, annak külön táblában tárolom az egyéb adatait., nem pedig a felhasználó táblába minden, vagy másikban.
User tábla
- id
- username
- password
- email
- tipus
(esetleg aktiv-e)User_Hirdetés kapcsoló tábla:
- user_id
- hirdető_idHirdető tábla:
- Id
- Hirdető neve
- Hirdető kora
- Hirdető egyéb adati
....
- Hirdetés_idHirdetés
- Id
- Hirdető_id
- Hirdetés címe
- Hirdetés leírása
- Hirdetés egyéb adati.
...Erről az adatbázis tervezésről mi a véleményetek? Ki mit tanácsol. Pozitív kritikát szívesen fogadok. Ez lenne az első amit magamtól csinálnék, és szeretném jól csinálni, nem pedig "betanulni" a rosszat
Ez teljesítménybe mennyire jó? -
Lacces
őstag
Köszi, adatbázist tudsz ajánlani tanulásra? Meg milyen developer programot?
Mindenkinek, mysql:
MySQL esetén, egy friss adatbázis van, hogyan lehet elérni, hogy az autoincreamenttel létrehozott id-ket úgymond újra rendezze. Létrehoztam az első rekordot, aminek egy 1-et adott. Létrejött közben a második is, annak 2-et, de létrejött még a 3. és 4.-ik is amit töröltem, és most ismét felvittem egy rekordot, és annak az id-ja már 5.
És azt szeretném, hogy ne ezek az ID-k legyenek benne: 1,2,5, hanem, 1,2,3.
Ha kitörlök egy elemet, akkor az ID-kat újrarendeze, és növekvőbe rakja.
Vagy ez felesleges?
Meglehet azt valahogy oldani, hogy újra "kiossza/rendezze" az id-kat, (nem találom a megfelelő szót)? -
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
-
Sziasztok! Tudnátok ajánlani valami könyvet, amiből elsajátíthatóak a DB kezelés alapjai?
-
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. -
Goose-T
veterán
válasz
sanzi89
#1332
üzenetére
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.
-
sanzi89
addikt
Ú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?
-
#1331
lakisoft
veterán
Sk8erPeter
#1330
lakisoft
veterán
válasz
Sk8erPeter
#1330
üzenetére
Morcos voltam
-
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.
-
martonx
veterán
válasz
rum-cajsz
#1323
üzenetére
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. -
#1322
sanzi89
addikt
Sk8erPeter
#1321
sanzi89
addikt
válasz
Sk8erPeter
#1321
üzenetére
Rendben, legközelebb igyekszem pontosabbnak lenni.
-
#1321
Sk8erPeter
nagyúr
sanzi89
#1318
Sk8erPeter
nagyúr
válasz
sanzi89
#1318
üzenetére
Abban igazad van, hogy írtad, hogy nincs kulcs, ez őszintén szólva kissé számomra elsikkadt a hsz.-ek után. DE ilyen alapon - ha már ilyen jól belejöttünk az egymásba való belekötésbe
- attól még tartozhat valami olyan mező is a táblához, ami alapján egyértelműen lehet azonosítani az adott sort (még ha nem is ténylegesen KULCS az adatbázis szintjén!!), de erről sem írtál SEMMIT, tehát fogalmunk nem lehetett az adatbázis-szerkezetedről sem.
Delphi? Mutasd már meg, itt hol írtál ilyenről egyáltalán: [link]. És ha Delphi, akkor mi van? Ez a rész a lényeg szempontjából miért érdekes? Attól még miért ne lehetne akár grafikus alapú adatbázis-kezelőből módosítani az adatbázist? Mi köze a kettőnek egymáshoz?
A sok-sok (!!) duplikációval kapcsolatban meg hadd idézzelek:
"Van benne 2 sor, ami totálisan megegyezik, minden mező értéke ugyan az."
Amit itt írsz, azt jelenti, összesen 2 sorral van problémád. Ebből tehát rohadtul nem derül ki az, amit a későbbiekben írtál le, hogy SOK duplikáció van, ergo NEM csak két sor."Van egy táblám, benne adatok."
Semmi információ arról, hogy ez Access lenne, és milyen adatokról van szó (értsd: adatbázis-struktúra, esetleg példa).Idióta visszakérdezgetések és a mostani, tök felesleges veszekedés és e-pénisz-villogtatás elkerülése érdekében pl. feltehetted volna a kérdést úgy (csak egy példa), hogy "van egy Access-táblám, semmilyen mező nem azonosítja egyértelműen a sorokat (nincs azonosítójuk), és elég sok sor duplikálva van. Milyen módon tudnám megszüntetni a duplikációt?
Struktúra:
ABCDE
Egy konkrét példa egy sorra (ilyenből van kettő):
XYZ"======
(#1319) -Zeratul- : ja, nyilván a kérdés tökéletes volt. Azért olvasd el a fentit, hogy hogyan lehetett volna elkerülni, hogy most itt ilyen óvodás hőzöngés alakuljon ki.
-
sanzi89
addikt
válasz
martonx
#1317
üzenetére
Értelmes válasz, hmmm.... Kérdésem:
"...SQL lekérdezéssel..."Válaszod:
"...Access grafikus tábla megjelenítőjében jobb gomb..."Van még kérdésed?
@Sk8erPeter
Jó, le kellett volna írom, hogy milyen adatbázis, ebben igazad van, de azért a Te válaszaid se voltak annyira hasznos infók. Szintén, SQL lekérdezés, Delphi-n belül, tök logikus, hogy használjak egy új adatbázis kezelő programot. Leírtam, hogy van benne 2 sor, ami dupla, erre megkérdezed, hogy mindegyik vagy csak 2. Leírom, hogy nincs kulcs, nincs azonosító, minden sor ugyan azt tartalmazza, erre beírod, hogy id szerint töröljek. Csak forgatni tudom a szemem...Egyébként a segítség kérésben igazad van, bocs érte, csak amilyen lekezelően írtad az első kommentedet, arra akartam reagálni.
-
#1316
Sk8erPeter
nagyúr
sanzi89
#1315
Sk8erPeter
nagyúr
válasz
sanzi89
#1315
üzenetére
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...
-
#1315
sanzi89
addikt
Sk8erPeter
#1307
sanzi89
addikt
válasz
Sk8erPeter
#1307
üzenetére
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. -
bpx
őstag
válasz
sanzi89
#1306
üzenetére
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 -
Goose-T
veterán
válasz
sanzi89
#1308
üzenetére
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.
-
#1311
sanzi89
addikt
Sk8erPeter
#1309
sanzi89
addikt
válasz
Sk8erPeter
#1309
üzenetére
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 | DebrecenEbből kellene az egyik Kis Pistát törölni.
-
#1309
Sk8erPeter
nagyúr
sanzi89
#1308
Sk8erPeter
nagyúr
válasz
sanzi89
#1308
üzenetére
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] -
#1308
sanzi89
addikt
Sk8erPeter
#1307
sanzi89
addikt
válasz
Sk8erPeter
#1307
üzenetére
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.
-
sanzi89
addikt
Ú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?
-
#1305
Sk8erPeter
nagyúr
rum-cajsz
#1304
Sk8erPeter
nagyúr
válasz
rum-cajsz
#1304
üzenetére
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. -
#1304
rum-cajsz
őstag
Sk8erPeter
#1303
rum-cajsz
őstag
válasz
Sk8erPeter
#1303
üzenetére
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)
-
#1303
Sk8erPeter
nagyúr
rum-cajsz
#1302
Sk8erPeter
nagyúr
válasz
rum-cajsz
#1302
üzenetére
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. -
#1301
sztanozs
veterán
Sk8erPeter
#1300
válasz
Sk8erPeter
#1300
üzenetére
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...
ez most komoly kérdés volt?
![;]](http://cdn.rios.hu/dl/s/v1.gif)
), az MS Access-ennek csak egy speciális vetülete. Az Access SQL meg különösen kilóg az SQL-ek sorából.
Új hozzászólás Aktív témák
- GYÖNYÖRŰ iPhone 13 Mini 128GB Pink-1 ÉV GARANCIA -Kártyafüggetlen, MS4173, 94% Akkumulátor
- ÁRGARANCIA!Épített KomPhone Ryzen 5 5600X 16/32/64GB RAM RX 9060 XT 8GB GAMER PC termékbeszámítással
- LG 39GS95UE - 39" Ívelt OLED / QHD 2K / 240Hz & 0.03ms / 1300 Nits / NVIDIA G-Sync / AMD FreeSync
- LG 27GR83Q-B - 27" IPS / QHD 2K / 240Hz & 1ms / NVIDIA G-Sync / FreeSync / DisplayHDR 400
- MacBook Pro 13, 14, 15, 16, MacBook Air M1, M2 M3 M4 bill magyarosítás lézerrel / sapkacserével
Állásajánlatok
Cég: Laptopszaki Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest