Query SQL e Oracle

[ceccus]

Salve,
No, no...l' ambiente Oracle IAS 10G non me lo sono dimenticato...è che come Application Server non può stare , per il momento, a competere sia con Websphere che con IIS/COM+.....mai provato a connetterlo con Sistemi CICS IBM ??
Poi, trattandosi di Oracle, sicuramente da piattaforma Microsoft utilizzerò un OLEDB Provider (anche se esiste l' ODBC)
Ti ricordo che in un ambiente "enterprise" (Aziendale) avrai sicuramente bisogno di gestire "Transazioni" , partendo da un ambiente "periferico" (Windows o Linux) e "propagando" la Transazione" su ambienti Mainframe , tipicamente CICS (Customer Information Control Sytem) e questo lo potrai fare SOLO ed ESCLUSIVAMENTE se utilizzerai un Application Server e un Driver di accesso ai dati XA compliant , quali appunto i Driver JDBC,ODBC, OLEDB.....

Ciao !!

[Deep73]

Ehi voi due.... allora mi spiegate una cosa fra tutti stì drivers ODBC e menate varie:

com'è che le mie (nostre) applicazioni si collegano ad Oracle SENZA alcun appoggio a ODBC e quanto di cui sopra? Anzi sul client non installiamo proprio nulla se non l'applicazione stessa.



Ergo: il driver ODBC non serve una cippa con Oracle.

[ceccus]

Salve,
Allora, prima di dire che il Driver ODBC o OLEDB non serve a nulla (e in questo caso parlare di Oracle è perfettamente equivalente a parlare di DBII e di Sybase o di SQLServer, per esempio)....di acqua sotto i ponti ne deve passare....
Primo : che tipo di applicazione è la Tua ??
Secondo : in che ambito si colloca (vale a dire Enterprise di basso livello o di alto livello, Home...)
Terzo : Se la tua applicazione , per funzionare, ha bisogno di transazioni
Quarto : Se la tua applicazione utilizza altre fonti Dati al di fuori di Oracle....
Quinto : se la tua applicazione è sviluppata per collquiare con piattaforme differenti (Es : Windows - IBM Mainframe)
Sesto : Come instauri la comunicazione fra l'applicazione Client (che immagino suddivisa almeno su 2 livelli) e il Server (in questo caso il DB....)

Ciao !!

[DavideDave]

ceccus...il fatto iniziale era...la tua "domanda"...."e dove mettiamo l'ODBC che è fatto in C?" e io ti ho risposto...sì ok...è fatto in C....ma per quanto riguarda Oracle è proprio l'unica cosa fatta in C...o quasi...

tra l'altro c'è sia quello di microsoft che quello di oracle

e cmq mi stai parlando di un DRIVER...sviluppato SPECIFICATAMENTE per ambienti microsoft...è utile SOLO in questi ambienti, e comunque RIMPIAZZABILE da altri drivers come il JDBC...che fanno le stesse cose...se non di piu'...e in maniera piu' performante..

[ceccus]

SAlve,
...e su questo siamo perfettamente d'accordo....ma converrai con me che chi sviluppa in maniera "Enterprise" su piattaforma Microsoft , non ne può fare a meno di QUEL Driver....e stiamo parlando almeno del 70% delle grandi aziende Mondiali....(quelle Italiane NON sono escluse, vedi la mia...)
Poi, il fatto di essere più o meno performante, non dipende SOLO dal Driver, ma anche dall' Ambiente in cui gira.....Oracle for Unix è più performante di Oracle for Windows....ma in questo il Driver non centra praticamente niente....anche perchè , ripeto, le caratteristiche più importanti di un Driver OLEDB/ODBC sono 2 :
1) Il rispetto delle regole XA per quanto riguarda le transazioni
2) il rispetto del protocollo di Two Phase Commit a cui tutti i Resource Manager devono sottostare (e il driver funge da Resource Manager del DB nei confronti del Transaction Coordinator utilizzato nell' Application Server....)
Tengo a precisare che NON è assolutamente polemica...è un dire esattamente come stanno le cose...tutto quà...

Ciao !!

[Deep73]

Originariamente inviato da ceccus
Salve,
Allora, prima di dire che il Driver ODBC o OLEDB non serve a nulla (e in questo caso parlare di Oracle è perfettamente equivalente a parlare di DBII e di Sybase o di SQLServer, per esempio)....di acqua sotto i ponti ne deve passare....
Primo : che tipo di applicazione è la Tua ??
Secondo : in che ambito si colloca (vale a dire Enterprise di basso livello o di alto livello, Home...)
Terzo : Se la tua applicazione , per funzionare, ha bisogno di transazioni
Quarto : Se la tua applicazione utilizza altre fonti Dati al di fuori di Oracle....
Quinto : se la tua applicazione è sviluppata per collquiare con piattaforme differenti (Es : Windows - IBM Mainframe)
Sesto : Come instauri la comunicazione fra l'applicazione Client (che immagino suddivisa almeno su 2 livelli) e il Server (in questo caso il DB....)

Ciao !!

Io ho detto che se ne può fare completamente a meno.
Riposte:
Primo - software client/server di cartella clinica ed integrazione metodiche classiche. Gestione intraoperatoria, degenza e flusso DICOM.
Secondo - vedi tu, per come è fatta può esser messa su un pc singolo del medico di famiglia fino ad un cluster multinodo che gestisce migliaia di clients. Dove va Oracle, l'applicazione gira.
Terzo - ovviamente sì.
Quarto - in genere no, a meno di richieste specifiche da parte del cliente, quel che si può importare in Oracle lo s'importa.
Quinto - solo Windows di norma. Qualche RIS in Unix per via delle metodiche.
Sesto - sfrutto direttamente il protocollo Oracle, senza passare per Net80. Linguaggio Delphi, componenti ODAC. Qualsiasi tentativo di usare ODBC è fallito miseramente a causa della lentezza e della instabilità di quel driver.

[ceccus]

Salve,
E 'abbastanza chiaro, ora , che quella applicazione è "cablata" su Oracle e , così come è, non sarà possibile nè integrarla con altri DB nè sarà possibile utilizzarla "pari pari" sostituendo il Database(Sybase, SQLServer, DB2)ma questa può essere una precisa scelta di progetto....nessun problema.
Immagina, per un momento di avere di fronte questo Scenario : 2 DB (Oracle da una parte e DB2 z/OS sull' altro...)
Oracle gira su rack centralizzati su Server Windows....
DB2 Z/OS gira nel proprio sistema TSO/CICS....Mainframe IBM
I 2 sottosistemi NON sono in comunicazione diretta fra loro....
L' unico modo di gestire una "transazione distribuita" è quello di utilizzare un'Application Server che abbia un suo Transaction Coordinator che funga da coordinatore delle transazioni. In ambiente Microsoft questo si esplica in COM+/DTC.
Per colloquiare con i 2 DB hai bisogno necessariamente di Driver OLEDB/ODBC che fungano da Resource Manager nei confronti del DB STESSO e che il coordinatore deve coordinare.
In questo scenario , i driver ODBC/OLEDB sono indispensabili, altrimenti il coordinatore non avrebbe Resource Manager a cui indirizzare le sue richieste , per esempio, di Commit o di Rollback.
Non solo, ma in questo scenario, l' applicazione se ne può tranquillamente "fregare" se "dalla parte di là" c'è Oracle o DB2....potrebbe esserci SQLServer e Sybase.....non cambierebbe proprio niente , tranne il Driver ODBC/OLEDB utilizzato......
Questo dà una notevole flessibilità in termini operativi , magari, e qui sono d'accordo, a scapito di performances....si tratta di trovare il giusto MIX....
Dimenticavo : l' esempio che ti ho portato NON è campato in aria...ma permette alla mia Azienda di sviluppare codice Multipiattaforma indipendente dal DB Utilizzato....e , in ambiente Enterprise, questo è fondamentale.. a maggior ragione per un Gruppo Bancario.......

Ciao !!