Sziasztok,
A MySQL tud közvetlenül fájlrendszerről beolvasni csv-t. Link
Kérdés, hogy a csv fájl jöhet webről?
Valami ilyesmire gondoltam:
LOAD DATA INFILE 'http://www.foo.com/foo.csv' INTO TABLE `database`.`table` FIELDS TERMINATED BY ... ROW TERMINATED BY...
Köszi
Sziasztok!
Oracle 11.2.0.1.0 kliens (win7 64 -re) telepítése után a kliens nem "működik".
Toad nem tud kapcsolódni a szerverhez, mert hiányolja a kliens programot.
Egyéb oracle kliens-t használó program sem találja.
Az összetevők másolódnak, path módsítása megtörténik, dll -ek exe -k
látszólag jó helyen és elérhetőek. Próbáltam rendszergazda jogú felhasználóval,
próbáltam rendszergazda ként, próbáltam 32 és 64 bites klienst telepíteni.
Próbáltam másik win7 -n is. Próbáltam "Administrator" és "Runtime" -t is.
A telepítés logban sincs hiba.
A telepítések próbálgatása között letakarítottam a kliens, még a
registry-ben felejtett bejegyzéseket is töröltem.
Viszonylag ritkán telepítek klienst, szóval, lehet h benéztem valamit,
de nem tudom mit.
G sem tudott olyat mondani amit amit nem jól csináltam.
Valakinek valami ötlete?
Kösz.
Üdv!
PostgreSQL táblában szeretnék sorokat frissíteni CSV fájlból. Ezt a megoldást olvastam több helyen, ill. a PgSQL doksiban sem láttam jobb megoldást.
Más lehetőség lehet még?
-- átmeneti tábla létrehozás
CREATE TEMP TABLE tmp_tbl (id int, val1 text);
-- átmeneti tábla feltöltése csv fájlból
COPY tmp_tbl FROM '/path/to/file.csv' delimiter ';' ; -- (FORMAT csv);
-- tbl tábla frissítése az átmeneti táblából
UPDATE tbl
SET val1 = tmp_tbl.val1
FROM tmp_tbl
WHERE tbl.id = tmp_tbl.id;
-- átmeneti tábla eldobása
DROP TABLE tmp_tbl;
Sziasztok!
Valamilyen űrlapkészítő programot keresek ami könnyen használható és később mssql-el is használható.
Viszont első körben annyit tudjon, hogy online meg lehessen jeleníteni és a kitöltött űrlapból lehessen pdf-et generálni.
Légyszíves aki használ ilyet és van benne tapasztalta ossza meg velem.
Köszönöm!
A probléma a következő. Van egy tábla amiben nevek vannak. Ha lekérdezést indítok:
A nev táblában az alábbi adatok vannak:
Andrea
Béla
Áron
Berta
SELECT nev FROM table ORDER BY nev
Akkor a rendezés nem lesz jó. Az eredmény az alábbi: Andrea, Berta, Béla, Áron
Hogy lehetne rendes UTF-8-as rendezést csinálni?
Ha a MYSQL tudja ezt akkor talán átállok arra...
Üdv!
Egy PgSQL adatbázisban van egy master-detail táblakapcsolat, pl.:
master (mid,name,typeid,desc...)
detail (mid,detail,val...)
Az mid mező egy serial (autoincrement) és ez a kulcsmező a master táblában, amivel a detail táblához kapcsolódik.
Ez alapján próbálom azt megoldani (pgsql script), hogy mindkét táblában egy rekordot szeretnék lemásolni (adott feltétellel, pl. mid=25), de az mid mezőt fel kellene használnom a detail táblában:
// eddig működik:
INSERT INTO master(name,typeid,desc)
(SELECT name,typeid,desc FROM master WHERE mid=25)
RETURNING mid;
//
// INSERT INTO detail(mid,detail,val)... ???
//
A "RETURNING mid" értékét el kellene tárolni, hogy felhasználjam az INSERT INTO detail... részben.
Hogyan lehet ezt megtenni?
Sziasztok,
Piackutatást végeznék. Adatok migrálásával kapcsolatban a következő dolgok érdekelnek, leginkább Linux alapú rendszereken:
1. Milyen disztribúciót használtok?
2. Milyen adatbáziskezelő rendszert használtok (több is megadható)?
3. Milyen eszközt használtok adatbázisok migrálására?
4. Migrálás közben használtok/használnátok transzformációkat?
5. Mik azok a kritériumok, amelyek teljesülése esetén lecserélnétek meglévő adatmigrációs eszközötöket?
6. Milyen migrálásokat végeztek? (Ad-hoc, időzített betöltés)
7. Adatmigráció milyensége (ETL folyamatok, backup készítés, OLTP adatbázisok szinkronizálása).
RDBMS built-in feature-ök nem játszanak (pl replikáció), illetve a dump alapú mentések sem, jellemzően tábla adatok migrációjáról van szó.
A válaszokat előre is köszönöm. Ha felmerülne még kérdés, akkor azt update-ként veszem fel.
Sziasztok.
Azt hiszem egy kicsit már belerágtam magam a dinamikus honlapok localhoston történő manipulálásába, de nem annyira, hogy tudjam is, mit művelek. Viszont ha kinyitok egy könyvet a témában, már tudom, mit keressek és hogyan.
A kérdésem rövid, de azt hiszem összetett is.
Egy ubuntura sikerült a LAMP-ot felraknom eddig, slackware-re nem.
Lila gőzöm sincs, hogy egy mysql adatbázis (melyből saját php kóddal már olvasni is tudtam) fizikailag hol is van.
Azért érdekelne ez, mert néha bizony "leáll" a böngészőben a phpmyadmin valami eszement üzenettel, melyet még nem értek és aggódom, hogy ha építek egy adatbázist valami CMS-sel, akkor egy végzetes halálnál nem tudom onnan kinyerni.
Szóval a teljesen kezdő kérdés:
meg tudom-e csinálni azt, hogy egyik distribben a nem tudom hova pakolódó adatbázist átrakom egy stabilabbnak vélt másik distribre? (Nos, ilyeneket nem találtam eddig könyvekben)
Az is érdekelne, hogy egy LAMP mikből, milyen csomagokból áll eltérő distribeknél. Mert ahogy tapasztaltam, slackware-ben még az apache csomagneve is más.(Vagy tévedek?)
Üdv!
Érdeklődöm, hogy milyen finomhangolást szoktatok PgSQL szerveren beállítani.
Ezt olvasgatom: http://www.postgresql.org/docs/9.1/static/runtime-config-resource.html
A környezet egyébként konkrétan egy kisebb adatbázisszerver:
-----------------------------------------
RAM: 16GB
Disks: 2*1TB raid1 (szoftveres) SATA HDD
CPU: intel Corei5
OS: CentOS7 x64
-----------------------------------------
Egyelőre az alapértékekből a doksi szerinti "shared_buffer" paramétert állítottam 32MB-ról 512MB-ra. Bár azt írja, hogy a fizikai RAM 25%-a is beállítható (ha van memóriád, pl. 1GB+).
Nagy terhelése nem lesz a rendszernek, max. 3-4 user használja majd egyidőben.
Más paraméterrel szoktatok még játszadozni?
Sziasztok,
Az elmúlt 3 napban egy 9.4.5-ben bejött hibát vadásztunk, amely bizonyos táblastruktúra, és updatelhető view kombinációjával jön elő. A hiba
mind windows-os, mind linux-os buildben benne van, sőt, a 9.5-ösben is reprodukálni tudtuk.
Itt a hiba leírása:
http://postgresql.nabble.com/BUG-13781-quot-unrecognized-node-type-quot…
Minimál teszteset elérhető, de esélyes, hogy zero-day exploit-ot lehet belőle csinálni, tehát amíg nincs javítás, nem lesz publikálva.
Tehát, ha PostgreSQL-t használó kódot fejlesztetek vagy üzemeltettek, akkor egyelőre maradjatok 9.4.4-en, ha pedig updateltek, akkor
érdemes lenne vagy visszamenni a régire (9.4.4). Annyit tudok még mondani, hogy ha forráskódból fordítottátok, akkor érdemes bekapcsolni
a --enable-cassert -et, mert ez legalább a crash-től megvéd. (Ubuntu server-en bizony kőkeményen crash-el)