Új hozzászólás Aktív témák

• #5254 Ispy nagyúr Sokimm #5253

  Új Válasz 2021-09-07 15:07:32 #5254

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Ispy

  nagyúr

  válasz Sokimm #5253 üzenetére

  React frontend+express backend? Mi most ezt a kombót használjuk, azure app service-ekkel vagy function appal (serverless). De ez inkább programozás kérdéskör, nem SQL, szóval itt offtopic.

• #5235 sztanozs veterán Sokimm #5200

  Új Válasz 2021-09-03 14:28:09 #5235

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  sztanozs

  veterán

  válasz Sokimm #5200 üzenetére

  Nem biztos, hogy értem, hogy mit szeretnél...
  Egyrészt a tűblákat érdemesebb volna ID-val csinálni (mert mi van, ha van két ugyanolyan nevű Kis Péter), de ha eddig nem kézzel volt szinkronizálva a tábla, hanem valami automatizmussal, akkor működhet a mezők "összekötése" utólag is.
  Amúgy a harmadik tábla csak egy query lenne, vagy ott is tárolnál valami plusz infót?
  Valahogy így raknám össze, ha sokat nem akarnék vacakolni:
  

  De rendesen, Id-kkal valahogy így nézne ki:
  

• #5233 Ispy nagyúr Sokimm #5227

  Új Válasz 2021-09-03 13:53:35 #5233

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Ispy

  nagyúr

  válasz Sokimm #5227 üzenetére

  Áhá, megvan, van egy fölösleges vessző a SET sor végén.

• #5232 Ispy nagyúr Sokimm #5230

  Új Válasz 2021-09-03 13:49:57 #5232

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Ispy

  nagyúr

  válasz Sokimm #5230 üzenetére

  Hát passzolom akkor, én amikor accesst használtam akkor is ms sql adatbázis volt mögötte, ilyen hackeket meg soha nem csináltam kézzel, csak VBA-ból max. A beépített varázsló szarokat meg soha nem használtam, mert borzalmasak.

• #5231 nyunyu félisten Sokimm #5227

  Új Válasz 2021-09-03 13:47:32 #5231

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  nyunyu

  félisten

  válasz Sokimm #5227 üzenetére

  Ha nagyon gonosz akarnék lenni, akkor:
  UPDATE new_table
SET Parameter1=old_table.Parameter1
WHERE old_table.AzonosParameter = new_table.AzonosParameter;

  (30+ évvel ezelőtti Teradata szintaxis, még a FROM clause bevezetése előttről.
  Kellett nekem ilyenekre SQL parsert írnom adattárház gyakornok koromban. )

  Ha meg nem akarnék az lenni, akkor:
  MERGE new_table u
USING old_table o
ON (u.AzonosParameter = o.AzonosParameter)
WHEN MATCHED THEN UPDATE
SET Parameter1=o.Parameter1;

• #5229 Ispy nagyúr Sokimm #5227

  Új Válasz 2021-09-03 13:39:18 #5229

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Ispy

  nagyúr

  válasz Sokimm #5227 üzenetére

  Mi a hibaüzenet? Az azért sokat tud segíteni, egyébként.

• #5219 Ispy nagyúr Sokimm #5218

  Új Válasz 2021-09-03 12:54:27 #5219

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Ispy

  nagyúr

  válasz Sokimm #5218 üzenetére

  Hun van a selectből a join?

  Ezt a where-es megoldást ne erőltesd, én nem legalább is nem szoktam:

  update x set mező=...
from x
inner join y on x.mező=y.mező

  Így csak azokat fogja frissíteni, ahol x-ben és y-ban is megtalálható a kapcsolat alapján a rekord.

  Ez mondjuk nem access, hanem ms sql, már rég nem accesseztem, szerencsére, de hátha megeszi.

  Kicsit furán kezeled az accesst, mint valami excel táblát. Nem mint egy relációs adatbázist.

  A gyémánt operátor egy kapcsos zárójel (leánykori nevén), ebben az esetben gondolom nincsen from és paraméterként értelemzi az access, egyébként ms sql-ben így illik a mezőkre hivatkozni, mert egyébként ha a mező neve egy operátor is, akkor a fordító nem tudja mit akarsz és hibára fut. Vagy ha gyilkos modon szóköz van a mező nevében, akkor is megpusztul. Ilyenkor a kapcsos zárójel közötti részt mezőként értelmezi.

  Egyébként valami ilyesmi is lehet a megoldás:

  update x set mező=....
from x, y
where (x.mező=y.mező)

  Csak én rosszul vagyok ettől a sytanxistól.

• #5212 nyunyu félisten Sokimm #5200

  Új Válasz 2021-09-03 11:20:24 #5212

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  nyunyu

  félisten

  válasz Sokimm #5200 üzenetére

  Nem teljesen értem, mire való a második táblád.

  Ha ebben csak a lehetséges táborozási opciók vannak felsorolva, és a harmadik táblába viszed fel a beérkezéskor, hogy melyik gyerek melyik opciókat kéri, akkor a harmadik táblába csak a gyerek nevét (vagy elsődleges azonosítóját/kulcsát), és az opció azonosítóját kell letárolnod.

  Ha a második táblában előre le vannak tárolva, hogy melyik gyerek mit kért (gyerekneve/azonosítója, opció párosként), akkor a harmadik tábla helyett kellene egy lekérdezés vagy nézet, ami ebből egy mátrixot rajzol.

  valahogy így:
  select nev, vega, reggeli, ebed, vacsora, szamtech, lovas, uszas
from (
select x.nev,
max(x.vega) vega,
max(x.reggeli) reggeli,
max(x.ebed) ebed,
max(x.vacsora) vacsora,
max(x.szamtech) szamtech,
max(x.lovas) lovas,
max(x.uszas) uszas,
from (
select gy.nev,
case when o.opcio = 'Vega' then 'I' else '' end vega,
case when o.opcio = 'Reggeli' then 'I' else '' end reggeli,
case when o.opcio = 'Ebéd' then 'I' else '' end ebed,
case when o.opcio = 'Vacsora' then 'I' else '' end vacsora,
case when o.opcio = 'Számítástechnika' then 'I' else '' end szamtech,
case when o.opcio = 'Lovas' then 'I' else '' end lovas,
case when o.opcio = 'Úszás' then 'I' else '' end uszas,
from gyerekek gy
join opciok o
on o.gyerek_id = gy.id) x --vagy o.nev = gy.nev, ha nevet tárolsz
group by x.nev);

  Ennek az eredménye egy ilyen táblázat lesz:
  NEV VEGA REGGELI EBED VACSORA SZAMTECH LOVAS USZAS
  Kiss Péter I I I I
  Nagy Anett I
  Török Flóra I I I

  (Bocs, nem nagyon vágom az Accesst, de elvileg szabvány SQL-ben is meg lehet feléje fogalmazni a kéréseket.)

• #5211 Ispy nagyúr Sokimm #5200

  Új Válasz 2021-09-03 10:48:02 #5211

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Ispy

  nagyúr

  válasz Sokimm #5200 üzenetére

  A kérdés, hogy minek a 3. tábla? Nem lehet, hogy az csak egy lekérdezés? Vagy minek még 1x letárolni mindent megint? Ez így nem túl adatbázisos megoldás.

  Először azt kéne definiálni, hogy pontosan mire akarod azt a táblát használni.

• #5210 bambano titán Sokimm #5209

  Új Válasz 2021-09-03 05:40:58 #5210

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  bambano

  titán

  válasz Sokimm #5209 üzenetére

  insert into table3 (gyereknevei) select gyereknevei from szemelyekadatai_tabla;

  de redundanciát pakolni az adatbázisba az elég gyors menetjegy a pokolba

• #5207 martonx veterán Sokimm #5200

  Új Válasz 2021-09-02 20:29:47 #5207

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  martonx

  veterán

  válasz Sokimm #5200 üzenetére

  Szvsz egy access makró programozás probléma, aminek a nyelve a VBA, nem pedig SQL probléma. Vagy pedig még a kérdés felvetést sem sikerült megértenem.
  Ezer éve volt, hogy access-t VBA-val programoztam, egy porickám se kívánja feleleveníteni.

Új hozzászólás Aktív témák