Keresés

Akkor hogy tudnám visszakapni az id-t?
ha insert ... values ... RETURNING ...
akkor működik.
ha insert ... select .... RETURNING ...
akkor nem!
Mit lehetne tenni?

insert into auto_i2 (SOMETHING)
  select SOMETHING from AUTO_INCREMENT where id = 9
  RETURNING id INTO logID;

Kipróbáltam Pro*C-ben, az sem tudja...

Sziasztok,

lenne egy kérdésem:
van egy táblám: auto_i2
ehhez szeretnék hozzáfűzni
egy rekordot a AUTO_INCREMENT táblából
úgy hogy a auto_i2 tábklában before insert trigger segítségével képződő
id-t visszakapjam a logID -be.
da sajnos a
ORA-00933: SQL command not properly ended
hibaüzenetet kapom.
az insert kipróbált, működik, ha kihagyom a "RETURNING id INTO logID" -t

insert into auto_i2
(
SOMETHING
)
select
SOMETHING
from AUTO_INCREMENT
where id = 9
RETURNING id INTO logID;
commit;

Végső esetben irány az Sql*Plus, azzal biztos látod...

Megvan az a tábla, de csak akkor látom, hogy ha megfelelő userrel vagyok bejelentkezve. Sysként miért nem látom?

Üdv Mindenkinek!
Oracle 10 Express-el kapcsolatban szeretnék segítséget kérni. Visual Foxpro 7-ből próbálgatom kezelni, de nem túl sok sikerrel.
Sikerült nagynehezen ODBC-n összehozni a kapcsolatot, de a saját driverével nem ment, csak egy utólag letöltött, újabb alverzióssal.
Létrehoztam egy táblát foxproból, amit onnan el is érek, de ha a webes felületén nézem az Oracle-t, ott nem találom a táblák között. Miért nem látom?
Segítségeteket előre is köszönöm!

Igen, ráadásul gyakran szokott az lenni, hogy kérnek valamit, majd aztán valami máshoz is kell később a ugyanaz. Na ezért aztán nem is szoktam a helyel törődni, csak hogy letároljak minden olyat, ami esetleg máshoz is kellhet majd.

Ja és köszi a linket, mindjárt áttanulmányozom. :)

Hát igen, korábban általában mindig az szokott lenni az első kérdésem, hogy OLTP vagy DW a rendszer... DW-nél valóban más a leányzó a fekvése, ahogy te is érzékeltetted... :o)

Kicsit akkor elmagyarázom a környezetet. Logikai ugyan az adatbázis, de Adattárház szervezésű. Úgy néz ki a dolog, hogy este a képviselők szépen feltöltik az adataikat az adatbázisba, aztán mi jól áttöltjük az adattárázba. Eleve egy szörnyet kreáltunk sok redundanciával, úgyhogy mégegy tábla ide vagy oda nem számít. Az eljárás az áttöltés része lesz, szóval ha épp az borul meg azt egyrészt látjuk, plusz magától újraindul ha az oracle hibát ad. Viszont ezt a táblát jól össze tudom majd kötni más táblákkal és riportálgathatom az utolsó négy látogatás különböző eladásait, satöbbit nyugisan és gyorsan. Plusz abban is gondolkodnom kell, hogy a BO, amivel riportálunk, alapvetően egyszerű táblák egyszerű összekötéséből ért. Szóval igazából ez a segédtábla máshol is használva lesz, hely meg van. :)

>Igazából ez csak egy segédtábla lesz, ami alapján megnézem, hogy a különböző látogatásokkor volt-e eladás, vagy készletszámolás.

Na és ez biztos jó ötlet? Önmagában logikai adatbázis-tervezés miatti force-olt redundancia, nem ördögtől való, de...
- Valami módon karban kell tartanod a segédtáblát is (tárolt eljárással), vélhetőleg elég gyakran. Ez is erőforrásigény ám.
- Ha befigyel a tárolt eljárás, akkor minek az inicializáló sql-en gyötörni magatokat (persze érdekes és szép a feladat l'art pour l'art is... ;) Azt fel sem tételezem, hogy a segédtábla kreáló sql-t mindig futtatni akarnátok, amint a bolt,datum páros valamelyike keletkezik/módosul/törlődik /igaz van amikor még akár ez is belefér/.
- _Annyira_ nem nagy nyereség érzésem szerint /mármint a kérdéses származtatott adatok ezen redundáns tárolása/, hogy megérjen egy külön segédtáblát, annak pontos adminisztrációjának nyügeivel.

>>...hogy a látogatások egy mezőben vesszővel elválasztva jelenjenek meg
>szerintem hagyja ez nem nekünk való. :))
Akkor hagyjuk? ;)
Pedig van rá elegáns megoldás, pl.: string aggregálás
http://www.oracle-base.com/articles/10g/StringAggregationTechniques.php

Hali,

A bolt, dátum egyedi azonosító. Viszont télleg az összes bolt kellene. Igazából ez csak egy segédtábla lesz, ami alapján megnézem, hogy a különböző látogatásokkor volt-e eladás, vagy készletszámolás. Majd aztán jól eldöntöm, hogy hányszor volt disztribúciója az adott terméknek a boltban.

Viszont az egyik komám is kapott egy érdekeset ma. Megintcsak a látogatás táblából, úgy kellene egy adott időszakra levállogatnia a látogatásokat, hogy a látogatások egy mezőben vesszővel elválasztva jelenjenek meg. Én mondtam neki, hogy szerintem hagyja ez nem nekünk való. :)) Mink csak egyszerű alapfokú sql-esek vagyunk, ráadásul autodidakták. Az összes jó kis megoldásotokat, amiket eddig adtatok nekem néha fel sem fogtam. De boldogan fogadtam a vállonveregetéseket, amiket most virtuálisan felajánlom nektek.

Hát nem tudom.... ;) Lehet, hogy reggel van még... ;)

Szerintem ha csak _egyetlen_ bolt utolsó négy látogatása kell (ahogy tisztességes OLTP-rendszerben valamelyest elvárható), akkor én szűrnék a boltra, csökkenően rendeznék a látogatásra, és venném az első négy rekordot. Valahogy így (nem teszteltem)

SELECT ROWNUM rn, kod, datum
FROM
(
SELECT kod,datum
FROM BOLT b
WHERE kod='szükésges bolt kódja'
ORDER BY datum DESC
)
WHERE rn<=4

Ami meggondolásra váró kérdések:
- Mi van, ha a (kod,datum) nem unique?
- Mi van, ha az _összes_ bolt utolsó négy látogatása kell, SQL-ben?
- Mi van, ha analitikus függvény nélkül kellene? ;) -> ez nem biztos, hogy ostoba felvetés; hiszen pl.: bankoknál az ügyfelek utolsó két tranzakciójának lekérdezése sokmilliós táblákon/equijoinokon, egyrészt bír feladat lenni, másrészt bír elgondolkodtató lenni.

Ó, még válogathatok is, köszönöm. De eredményt nem vagyok hajlandó hírdetni. :)

select *
from (
select boltkod, datum, statusz, row_number() over (partition by boltkod order by datum desc) sorszam
from latogatasok
)
where sorszam <= 4
order by boltkod, sorszam
/

Sokkal elegánsabb, mint amit én írtam volna, köszönöm. :)

Nemtom mennyire elegáns :)

 

 

SELECT kod,datum FROM (
SELECT ROWNUM rn,a.kod,a.datum,m FROM (SELECT kod,datum FROM BOLT b ORDER BY kod,datum
)a,(
SELECT kod,MAX(rn) m FROM (SELECT ROWNUM rn,kod,datum FROM (SELECT kod,datum FROM BOLT
ORDER BY kod,datum)) GROUP BY kod
) c WHERE a.kod = c.kod
) WHERE rn > m-4

Üdv urak,

Olyan kérdésem lenne, hogy hogyan tudom a legkönnyebben leválogatni egy bolthoz tartozó utolsó négy látogatást?

A tábla tök egyszerű, boltkód, dátum, státusz.

Najó, ha nem is a legkönnyebben, de a legelegánsabban. :)

köszönöm, megnézem

Hi!

Viszont

 

letölthető :

http://www.linuxfromscratch.org/blfs/view/svn/general/unixodbc.html

 

telepíthető :

http://www.easysoft.com/developer/interfaces/odbc/linux.html

Szia
köszönöm, mindkét doc hasznos volt,
de...
Az eredeti kérdés:
"tud valaki redhat ent. alatti 10g és mssql közé MŰKÖDŐ odbc -t?"
mert ezek a technikák jók, csak éppen feltételezik egy odbc jelenlétét a szerveren.
Ez nekem pedig nincs sajnos.

A 115098.1-es doc id szintén ezt taglalja, csak ux környezetben

Köszönöm, megnézem

A metalink-en (doc id : 114820.1) találsz megoldást, hogy hogyan lehet összekapcsolni oracle és mssql adatbázisokat  linken keresztül.

 

"Ha az MsSql rendszer megpusztul mi történik az Oracle-vel?"
Semmi, a lekérdezők nem tudnak lekérdezni míg a másik (tőlünk független)
cég (aki diszponál az MSSQL-es adatbázis felett) ki nem javítja a hibát.
Nem online a frissítés hanem időnként Oracle oldalról ellenőrizzük van-e már új adat.
ha van átvesszük ha nincs akkor nem.
Azt hiszem talán ez lehet a lazán csatolt...

Az én értelmezésemben ez
- "MSSQL táblát átemelni egy struktúrájában (még mező neveiben is) 100% -ig azonos Oracle táblába." => (tábla-)replikálás heterogén adatbázisok között.
- "Én az ORACLE oldalon állok, a másik oldalt nem tudom semmilyen mértékben sem befolyásolni."=> A távoli MsSql rendszer autonóm, nem piszkálható.
- "Minél kevesebb ODBC igénybevételével." => cél , hogy nincs újabb réteg az architektúrában azaz maradjon csak a két (adatbázis)szerver: ami táblareplikálás esetén akár logikus elvárás is lehet.

Nyitott kérdések:
- Lazán/Nem lazán csatolt rendszerek más szóval online/offline frissítés/szinkronitás kérdése. Ha az MsSql rendszer megpusztul mi történik az Oracle-vel? Meg egyéb szokásos replikálás tervezési kérdés lásd korábbi threadeket, itt a fórumban..
- A GUI-s egyidejű hozzáférés témája esetleg az üzleti logikával megspékelve természetesen egy külön thread....

Nem tudom ki hogy van vele, még mindig sok technikai lehetőség van, és érdemes további tervezési iterációkat tenni az optimális megoldás érdekében.

Nekem jdbc-oracle-val van tapasztalatom, es semmi bajom vele.

Feladat:
MSSQL táblát
átemelni egy struktúrájában (még mező neveiben is) 100% -ig azonos Oracle táblába.
Minél kevesebb ODBC igénybevételével.
DE adat nem kerülhet ki 3. állományba se dump se export se semmilyen
más módon még titkosítva sem.
A központi ORACLE adatbázisnak kell "kinyúlkálnia" a külső rendszerekbe,.
amiből csak egy az MSSQL alapú alkalmazás.
Én az ORACLE oldalon állok, a másik oldalt nem tudom semmilyen mértékben sem befolyásolni.
Ők adják a hozzáférést az export táblákhoz, tárolt eljárásokhoz,
én vagy át tudom venni vagy nem (az már az én bajom ha nem).
Szóval erről lenne szó, remélem érthetően leírtam.

Igen a KIÍRÓK SZERINT ez a közvetlen elérés
a text szócskától irtóznak sajnos.
Én ugyanúgy nem értem ahogy Ti sem.

"Ha irok javaban egy programot, ami jdbc-n olvas mssql-bol, es jdbc-n ir oracle-ba, az közvetlen eleres? "
Jelen pillanatban épp így csinálom (csak nem java-ban),
de ez a megoldás 2 db odbc-t használ (egy mssql felé egy meg Oracle felé)
ezt gondoltam lecsökkenteni egyre.

(Nagyon sok rossz tapasztalatom van az ODBCékkel.
én meg tőlük irtózom. :))

Jo, hat nyilvan a feladat teljes specifikacioja nelkul csak a kodben lovoldozunk.

vajk