jo, no. Napadlo mne to. Ale nechtelo se mi experimontovat.
Příspěvky odeslané z IP adresy 2001:718:2601:258:743e:808b:5d17:2d47...–
Tech zavorek jsem tam mel vic, protoze jsem tam puvodne chtel natlacit vsechny radky. Ale, proste, tak, jak jsem to mel, tak to resit neslo. Jak pises, musim tam mit radek u toho SELECT. Ktery jsem tam cpal sice z dual nebo dest nebo, jak to funguje, ale bylo mi zahadou, ze si veme nekde potom ta data do hornich radku.Proste, jak to popisujes, a jak mi to predelal kolega, tak je mi to uz jasne a nejspis bych to dokazal pak uz dosestavit i sam :)
dik, vyreseno. Vcera se mi podarilo sehnat kolegu, ktery dela s oraclem jinde. Tech problemu tam bylo vic. Vysledek je neco takoveho. Jen je treba jeste pridat u nvl s datumy prevod stringu pomoci to_date.
MERGE INTO DATA_WAREHOUSE.CIS_PROJEKTU_SU dest USING (SELECT '152' AS
ID, '21-04364S' AS CIS_PROJEKTU, 'Civilistní tendence v české
meziválečné hudební kultuře' AS NAZEV_KRATKY, 'Civilistní tendence v
české meziválečné hudební kultuře' AS NAZEV,
'https://projekty.slu.cz/evid3_app.php?what=form_export2&do=export_is2_view&idform_export2=152'
AS URL, to_date ('2021-01-01', 'RRRR-MM-DD') AS DAT_ZAHAJENI, to_date
('2023-12-31', 'RRRR-MM-DD') AS DAT_UKONCENI FROM dual) src ON
(dest.ID=src.ID) WHEN MATCHED THEN UPDATE SET
CIS_PROJEKTU=src.CIS_PROJEKTU, NAZEV_KRATKY=src.NAZEV_KRATKY,
NAZEV=src.NAZEV, URL=src.URL, DAT_ZAHAJENI=src.DAT_ZAHAJENI,
DAT_UKONCENI=src.DAT_UKONCENI WHERE nvl (src.CIS_PROJEKTU, '0') <> nvl
(dest.CIS_PROJEKTU, '0') OR nvl (src.NAZEV_KRATKY, 'nevyplněno') <> nvl
(dest.NAZEV_KRATKY, 'nevyplněno') OR nvl (src.NAZEV, 'nevyplněno') <>
nvl (dest.NAZEV, 'nevyplněno') OR nvl (src.URL, '0') <> nvl (dest.URL,
'0') OR nvl (src.DAT_ZAHAJENI, '01.01.2100') <> nvl (dest.DAT_ZAHAJENI,
'01.01.2100') OR nvl (src.DAT_UKONCENI, '01.01.2100') <> nvl
(dest.DAT_UKONCENI, '01.01.2100') WHEN NOT MATCHED THEN INSERT (ID,
CIS_PROJEKTU, NAZEV_KRATKY, NAZEV, URL, DAT_ZAHAJENI, DAT_UKONCENI)
VALUES ('152', '21-04364S', 'Civilistní tendence v české meziválečné
hudební kultuře', 'Civilistní tendence v české meziválečné hudební
kultuře',
'https://projekty.slu.cz/evid3_app.php?what=form_export2&do=export_is2_view&idform_export2=152',
to_date ('2021-01-01', 'RRRR-MM-DD'), to_date ('2023-12-31', 'RRRR-MM-DD'))
Ted uz mi ten dotaz dava vetsi smysl.
- Tam mne matlo, ze mi tam schazel ta zdrojova data, to je ten prvni SELECT.
- WHERE podminky, ze mam pridat k UPDATE jsem vcera jeste vygoogloval na jinem priklade
- ale, uz mne nenapadlo je upravit o nvl() (ale, mozna, ze by to stacilo pridat k te casti se SELECT)
- a jeste je teda treba pridat ty konverze string-datum na to_date() u UPDATU
Podle vseho to asi ted funguje tak, jak by asi melo. Nicmene, mozna to budeme delat uplne jinak. Udelame pomocnou tabulku, do ktere nasoukame vsechna data z mysql a pak je pomoci jednodussiho merge updatujene do te druhe, kde hlidame datumy. Tam je hlavne podstatne, aby do externiho systemu neslo prilis dat, kdyz nemusi. Jinak bychom to tam posilali cele. A tez bude mit kolega vetsi kontrolu nad tim, co jde do toho externiho programu. Pac do mych php nevidi, ale do db ma pristup a umi si to opravit podle potreby.
Ta chyba mohla byt temi apostrofy, ozavorkovanim nebo kolega jeste narazil na limit delky pole NAZEV, tak jej rozsiril. No, po jeho opravach ten dotaz zatim nehlasi zadne chyby, tak snad to pobezi, az se to spusti naostro :)