Keresés

1. Számos szövegszerkesztő tud konvertálni különféle kódkészletekbe/ből.

2. Van külön konvertáló program, a neve iconv.

3. Az Oracle kliensprogramja is tud konvertálni, ha a NLS_LANG-ot beállítod (pl)

Nyilván így van. nem is azt szeretném, hogy a program kitalálja a felhasználó helyett, hogy milyen kódolású a fájl,

hanem hogy "A" kódolású fájlt hogyan kell "B" kódolásban insert-álni.

Alapvetően az a gond, hogy a számítógépnek nem mond semmit az, hogy 'jó'. Tehát egy emberi lény kell, aki megállapítja, hogy az input milyen kódolásban van a file; azután vagy konvertál valami egyeztetett formára, vagy az input után húzza a NLS_LANG-ot.

Sziasztok!

Nekem is lenne egy karakter kódolással kapcsolatos problémám
Külső fájlból töltök be adatokat. Mivel különböző platformokon készülnek ezek az állományok,
valahogyan át kellene kódolnom az input adatokat betöltés közben, hogy a helyes ékezetes karakterek tárolódjanak el.

A DBMS_SQL package használom ebben az esetben. 

Hol és hogyan tudok beavatkozni, hogy a helyes kódolással kerüljön be az adat?

Itt egy példa hogy kb. miről lenne szó:

DECLARE

  l_input VARCHAR2(50) := 'BŁcsŁszentl szl˘ K?zs?g ?nkorm nyza';
  l_output VARCHAR2(50);

BEGIN

  EXECUTE IMMEDIATE 'CREATE TABLE other_cs(mezo VARCHAR2(50))';

  cs_pelda(p_param => l_input);

  SELECT MAX(mezo)
     INTO l_output
    FROM other_cs;

  dbms_output.put_line(l_input || chr(10) || l_output);

  EXECUTE IMMEDIATE 'DROP TABLE other_cs purge';

END;

/*
CREATE OR REPLACE PROCEDURE cs_pelda(p_param IN varchar2) AS
  cursor_name INTEGER;
  rows_processed INTEGER;
BEGIN
  cursor_name := DBMS_SQL.OPEN_CURSOR;
  DBMS_SQL.PARSE(cursor_name,
                            'INSERT INTO other_cs (mezo) values (:x)',
                            dbms_sql.native);
  DBMS_SQL.BIND_VARIABLE(cursor_name, ':x', p_param);
  rows_processed := DBMS_SQL.EXECUTE(cursor_name);
  DBMS_SQL.CLOSE_CURSOR(cursor_name);
EXCEPTION
  WHEN OTHERS THEN
    DBMS_SQL.CLOSE_CURSOR(cursor_name);
END;
*/

Note to self: dokumentálni kellene valahol, hogy a Pro*C furcsa hibákat produkálhat (beleértve pl a comment végének nem-érzékelését), ha:

1. a forrásprogramban (ami ugyebár réges-régen egy távoli galaxisban is készülhetett) egybájtos kódolású (pl latin2) ékezetes betűk vannak

2. a NLS_LANG-ban (ami mondjuk a terminálom pillanatnyi beállításához van igazítva (vö LC_CTYPE)) pedig AL32UTF8-van

megoldás (Makefile):

%.pc: %.c

       NLS_LANG=american_america.EE8ISO8859P2 proc ...

Köszönöm, de ebben az esetben ez nem probléma, sőt inkább előnyös.

Köszönöm!

pedig hányszor belefutottam már. és mégis mindig menetközben jövök rá újra, hogy igen, nem lehet a session charsetet megváltoztatni. 

akkor viszont muszáj ott kutatni hogy ahogy és ahol létrehozod a connection-t, hogyan lehet megadni a charsetet.

Nem volna rossz, de sajnos minden doksi azt írja, hogy character set -et nem lehet 'alter session' -nel

proC/OCI-ban sajnos nincs tapasztalatom. de ha több connection-öd van, akkor azoknak a charsetjét egyesével beállíthatod ha végrehajtasz bennük egy-egy alter session-t.

Vajk

Köszönöm a választ, sajnos nem ez volt a kérdés, valószínűleg én fogalmaztam bénán.

Egy darab kliensoldali programot szeretnék összetákolni különböző részekből, különböző adatbázis-kapcsolatokkal, különböző NLS_LANG/NLS_NCHAR beállításokkal. OCI-ban ugyebár akárhány OCIEnvNlsCreate-et használhatok, azon kívül meg minden mezőre/bindváltozóra megadhatom (OCIAttrSet) a OCI_ATTR_CHARSET_FORM-ot, meg a OCI_ATTR_CHARSET_ID-it. Namostam ez nem látszik menni a Pro*C-vel.

nem árt óvatosnak lenni. ha leklónoznak egy adatbázist, pl csinálnak a prod-ról egy copyt teszteléshez, fejlesztéshez, akkor alapból a dbid nem változik meg, a két adatbázisnak ugyanaz lesz. és mivel nem nagyon szerepel sehol, nem nagyon feltűnő. a dbid a fileokban azonosítja hogy melyik adatbázishoz tartoznak.

én szeretek olyan azonosítókat használni, amikről tiszta hogy ki mikor hogyan mit csinál velül. a dbname nekem sokkal szimpatikusabb. az az adatbázis neve, lehet róla beszélni, tudjuk mikor mi történik vele. olyan is van hogy két adatbázisnak ugyanaz a dbname-ja, de azt tudjuk előre hogy ilyen lesz, és hogy miért. 

Vajk

hogyabúbánatba ne lehetne. ez az egyik lényege az adatbázisnak. 

a db belül tárolja abban a charsetben, amit a kreáláskor megadtál. manapság al32utf8 a szokás. amikor konnektálsz, akkor a sessionnek van egy charsetje, és az adatbaázis oda-vissza konvertál. az al32utf8 adatbázishoz konnektálok mswin1250-es sessionnel, küldök egy microsoft ő betűt, és szépen letárol egy unicode ő betűt. valaki más hozzákonnektál egy isolatin2 (iso8859-2) sessionnel, kiolvassa, és szépen kap egy isolatin2 ő betűt. 

az nls_lang környezeti változó, meg mindenféle context történetek csak arról szólnak hogy a kliensek mindenféle módszereket használnak arra hogy kitalálják milyenre kell állítani a session charsetet. (meg a nyelvet, dátumformátumot, számformátumot, időzónát, egyéb locale specifikus beállításokat.)

de ez téged mind nem érdekel, használod az alter session set nls_lang= sql commandot bátran, és kész.

Vajk

Igen a DBID a db-t, egyértelműen azonosítja.

Szerintetek lehetséges-e Pro*C-ben connection-önként vagy CONTEXT-enként más-más karakterkészletet(*) használni? Ez azért volna jó, mert esetenként a program különböző komponensei különböző adatbázisokkal dolgoznak, és esetleg szükség lehet rá, hogy különböző beállításokkal menjenek (mondjuk az egyik egy fájlt akar írni, rögzített utf8 karakterkészlettel, a másik a felhasználóval kommunikálna, és a pillanatnyi LC_CTYPE függvényében állítaná be a NLS_LANG-ot).

Ilyesmiket próbáltam:

1. a két említett környezeti változó cseréje futás közben (setenv(3)): nem hat rá, úgy tűnik egyszer olvassa be, induláskor

2. a CONTEXT-ből kiszedni az OCIEnv-et (SQLEnvGet), aztán azt megerőszakolni: OCIAttrSet(OCI_ATTR_ENV_CHARSET,<number>)

az OCI leírás lebegteti, hogy ilyet esetleg csinálni, de csak minden más OCI hívás előtt. Hát nekem nem ment; ORA-24315: illegal attribute type
3. kétségbeesés, hajtépés: ez sem vált be...

(*) Illetve karakterkészlet-párost, az egyik a 'sima', ami a NLS_LANG harmadik mezőjéből jön, és a 'national', ami a NLS_NCHAR-ból. Az elsőt használja általában, a másodikat a 'CHARACTER SET IS NCHAR_CS' attribútumú mezőkhöz. (Lásd még az OCIEnvNlsCreate két utolsó paraméterét.)

Sziasztok!

Sajnos bizonyos esetekben nem tudom elkerülni a SP-k verziózását. Ehhez kellene egy adatbázis egyedi azonosító.

A V$DATABASE -ban található DBID minden kétséget kizáróan azonosítja az adott ORACLE adatbázist?

Ha nem, akkor mit használjak a szerver/adatbázis beazonosításához? (Egy adatbázis minden esetben egy szerveren található)

üdv: dz

koszi! kicsit raal a kezem az union all-ra, uniont keruljuk mint a leprast :)

Bocsánat, hogy belekontárkodok, de szerintem nem kell union all csak union, mert úgy mind a 3 select groupnak belekerülne minden sora,

és a rownum-ot ki kell emelni a group-ból.

Példád alapján, valahogy így:

with a as (select rownum r, a1.* from (select oszlop, count(*) db from ... group by ...) a1)
       b as (select ...
       c as (select ...
       u as (select r from a union select r from b union select r from c)
select a.oszlop, a.db, b.oszlop, b.db, c.oszlop, c.db from a,b,c,u
where u.r=a.r(+)
   and u.r=b.r(+)
   and u.r=c.r(+);

üdv: dz

with a as select rownum r, oszlop, count(*) from ... group by ...

       b as select ...

       c as select ...

select a.oszlop, a.db, b.oszlop, b.db, c.oszlop, c.db

from a,b,c,(select r from a union all select r from b union all select r from c) x

where x.r=a.r(+)

  and x.r=b.r(+)

  and x.r=c.r(+);

Például. Biztosan van szebb is, de felesleges rajta agyalni, mert ahol ilyenre van szükség, ott valami másutt nagyon-nagyon-nagyon el van rontva.

Vajk

itten most relációs adatbáziskezelésről beszélünk. attól relációs, hogy az egy sorhoz tartozó különböző oszlopokban levő értékeknek köze van egymáshoz. ha az első sor az hogy sanyi, szőke, 1999, 175 akkor az azt jelenti hogy sanyi 1999ben született, szőke és 175 cm magas.

amiről beszélsz, ott a táblát nem tekinted relációnak, nincs kapcsolat az oszlopok között. akarod tudni a nevek listáját gyakorisággal, a hajszínek listáját gyakorisággal, szüldátumok listáját gyakorisággal. tiszta sor, csak akkor ez három külön reláció, három külön lekérdezés, három külön aggregálás. az hogy te egyben, egymás mellett akarod látni őket, az formaság, nem relációs adatbázis kezelés. az elvárt kimenetben az első sor első és harmadik mezője között nincs semmilyen kapcsolat, nincsenek relációban egymással. 

persze meg lehet csinálni, csak még workaroundnak is rossz. tipikus főiskolai házifeladat.

Vajk

elnézést, elírtam az oszlophivatkozás nem t hanem A (alias) mindenhol

Már miért lenne így? 

Vonatkoztass el a látottaktól annyiban, hogy az 'csak' egy tábla kimeneti megjelenítése, mindegy hogy 3 vagy akárhány oszlopról van szó a megvalósítást illetően.

A téma az lenne amit és ahogy írtam, ez egy tábla oszlopaiban lévő különböző értékek. annyi, hogy azok előfordulását (számosságát) mindig az oszlop mellé tett count értékeket tartalmazó +1 oszlopba kellene  tenni. 

Gyakorlatilag ezt query-t kellene a példa output szerint 'összetenni egymás MELLÉ':

SELECT A.oszlop_1,
COUNT(t.oszlop_1) db
FROM table A
GROUP BY A.oszlop_1
;

SELECT A.oszlop_2,
COUNT(t.oszlop_2) db
FROM table A
GROUP BY A.oszlop_2
;

SELECT A.oszlop_3,
COUNT(t.oszlop_3) db
FROM table A
GROUP BY A.oszlop_3
;

group by, rownum, union all, pivot

Te is érzed, hogy ez az eredmény ez három tábla egymáshoz ragasztva. Semmi közük egymáshoz.

Vajk

Sziasztok,

Ötleteket várnék, kérnék az alábbi, egy, UGYANAZON tábla KÜLÖNBÖZŐ oszlopaiban szereplő értékeknek a darabszámára.

Így kellene a végleges eredménynek kinéznie:

Köszönöm, ez tökéletes lesz. :)

Végül az lett, hogy a temp táblával összahasonlítottam az oszlopokat és csak 5 esetben tért el, így elég könnyű volt megtalálni.

igen, az egyik leghasznosabb feature :)

korrekt!!

használod is? mert én ismerni ismerem, de sosem használtam, ezért sem jutott eszembe.

Szia!

Próbáld meg a DML Error Logging feature-t.

(10gR2-ben és az újabbakban)

SQL> create table SCOTT.HIBA_ORA
2 (
3 ORA_ERR_NUMBER$ NUMBER,
4 ORA_ERR_MESG$ VARCHAR2(2000),
5 ORA_ERR_ROWID$ UROWID(4000),
6 ORA_ERR_OPTYP$ VARCHAR2(2),
7 ORA_ERR_TAG$ VARCHAR2(2000),
8 EMPNO VARCHAR2(50),
9 DATUM DATE default sysdate
10 );

Table created
SQL> INSERT INTO scott.emp
2 (empno, ename, job, mgr, hiredate, sal, comm, deptno)
3 SELECT empno - 4000,
4 ename,
5 job,
6 mgr,
7 hiredate,
8 CASE
9 WHEN job = 'MANAGER' THEN
10 sal + 100000000
11 ELSE
12 sal
13 END sal,
14 comm,
15 deptno
16 FROM scott.emp log errors
17 INTO scott.hiba_ora('EMP INSERT ERRORS') reject LIMIT unlimited;

22 rows inserted

SQL> SELECT ORA_ERR_MESG$, ORA_ERR_TAG$, EMPNO FROM scott.hiba_ora;

ORA_ERR_MESG$                                                                                                  ORA_ERR_TAG$      EMPNO
--------------------------------------------------------------------------------------------------- ------------------------ --------
ORA-01438: a megadott érték hosszabb, mint amelyet az oszlopra definiált pontoss EMP INSERT ERRORS 3566
ORA-01438: a megadott érték hosszabb, mint amelyet az oszlopra definiált pontoss EMP INSERT ERRORS 3698
ORA-01438: a megadott érték hosszabb, mint amelyet az oszlopra definiált pontoss EMP INSERT ERRORS 3782

SQL> drop table scott.hiba_ora purge;

Table dropped
SQL> delete from scott.emp t
2 where t.empno not in (7369,7499,7521,7566,7654,7698,7782,7788,7839,7844,7876,7900,7902,7934);

11 rows deleted

mi az hogy sok? copy paste csodákra képes. 100 felett meg írnék egy selectet ami előállítja a selecttet ami kell. nem érdemes sok energiát tenni bele, mert csak egyszer kell.

Vajk