Domanda

Prima un po 'di sfondo. La mia azienda sta valutando se migreremo o meno il nostro database Informix su Oracle 10g. Abbiamo diversi programmi ESQL / C. Ho esaminato alcuni dei workbench di Oracle Migration e ho confuso alcuni test. Ora sono arrivato a realizzare alcune cose.

Innanzitutto, abbiamo istruzioni sql dinamiche che non gestiscono affatto valori null. Da quello che ho letto, devo modificare manualmente le query per utilizzare la funzione nvl () o implementare le variabili dell'indicatore. Qualcuno può confermare se sono necessarie modifiche manuali? Il minor numero di modifiche manuali che dobbiamo apportare ai nostri programmi ESQL / C convertiti, meglio è.

In secondo luogo, abbiamo diverse query che estraggono date da varie tabelle ecc. e in Informix le date sono trattate come tipo long, il numero di giorni dal 31 dicembre 1899.

In Pro * C, in quale formato viene selezionata una data? So che non è numerico perché ho provato a selezionare il campo della data nella mia variabile lunga e ho ricevuto un errore Oracle che indicava "NUMBER previsto, ma ho ottenuto una DATA". Quindi suppongo che dovremmo modificare il modo in cui stiamo selezionando i campi data - o selezionare un campo data in modo convertito in modo che diventi un lungo (cioè, # di giorni dal 31/12/1899), o cambiare l'host variabile per abbinare ciò che Oracle sta restituendo (che cos'è quella stringa?).

È stato utile?

Soluzione

Per convertire le date dell'oracolo (che sono archiviate in formato interno Oracle) in un numero intero lungo, dovrai modificare le tue query. Utilizza la seguente formula per le date:

to_number (to_char (date_column, 'J')) - to_number(to_char(to_date('12/31/1899', 'MM/DD/YYYY'), 'J'))

Il formato del sistema Oracle 'J' (per la data giuliana) è un conteggio del numero di giorni dal 31 dicembre 4712 a.C. Se vuoi contare da una data successiva, dovrai sottrarre il conteggio del giorno giuliano di quella data successiva.

Un suggerimento: invece di alterare tutte le tue query nei tuoi programmi (che possono creare problemi e introdurre bug), crea un set di viste in uno schema diverso. Queste viste verrebbero nominate come tutte le tabelle, con tutte le stesse colonne, ma includevano le formule NVL () e date () (come sopra). Quindi punta la tua applicazione sullo schema di visualizzazione piuttosto che sullo schema della tabella di base. Molto meno test e meno posti per perdere qualcosa.

Ad esempio, inserisci tutte le tue tabelle in uno schema chiamato " APPS_BASE " (definito dall'utente " APPS_BASE " ;. Quindi crea un altro schema / utente chiamato " APPS_VIEWS " ;. In APPS_VIEWS crea una vista:

CREATE OR REPLACE VIEW EMP AS
SELECT name, birth_date
FROM   APPS_BASE.EMP;

Altri suggerimenti

Ya. Dovrai modificare le tue domande come descritto.

long ti sta inciampando. lungo ha un significato diverso in Oracle. Esiste un tipo DATE specifico. Generalmente quando si seleziona uno si utilizza la funzione TO_DATE con un formato, per ottenere il risultato come VARCHAR2, esattamente nel formato desiderato.

Probabilmente non ti ha ancora colpito ma tieni presente che in Oracle i campi VARCHAR2 vuoti sono NULL. Non vedo alcuna logica dietro questo (probabilmente perché vengo dalla terra di Informix) - tienilo a mente. Penso che sia stupido - la stringa vuota di IMHO è significativa e diversa da NULL.

Modifica tutti i tuoi campi VARCHAR2 in NOT NULL DEFAULT '-' o qualsiasi altro valore arbitrario, oppure usa gli indicatori in TUTTE le tue query che restituiscono campi VARCHAR2 o usa sempre NVL ( ) .

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top