AS/400 - Linked server - Got it!
tiriamoavanti
1) Ho creato un DSN usando il driver ODBC del Client Access di IBM
Parametri da ricordare:
- libreria di default
- account d'accesso
- conversione CCSID 65535
- consentire scrittura
2) Ho creato un linked server con nome di fantasia
Parametri obbligatori:
Nome prodotto: nome sistema AS/400 (cfr. DSPNETA)
Origine dati: nome dsn (odbc) appena creato
Ed eccoci in pista:
select * from AS400.S65B1C2E.LIB1.PARAMPF
record restituito: 1 20080101 20080630
inizio a sentirmi bene felice!!!! :)
INSERT AS400.S65B1C2E.COVIMV2.PARAMPF ([KEY],DATAI,DATAF)
VALUES('2','20070101','20070630')
"OLE DB error trace [OLE/DB Provider 'MSDASQL' IRowsetChange::InsertRow
returned 0x80004005: "
Rovisto in internet, nei manuali, in usenet... poi l'intuizione giusta:
SOTTO AS/400 IL LOG DELLE TRANSAZIONI *NON* E' OBBLIGATORIO!!!
Si signori, in AS400 quando si crea una tabella si deve dichiarare se è
sottoposta a a "journal" (nome AS400 del log); il default è che le modifiche
ai record *non* siano loggate!
Invece SQLServer tenta sempre di creare una transazione per proteggere
l'integrità del sistema (acid, ricordate?)...
E le due cose danno si vede qualche leggerissimo conflittino :)
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED
INSERT AS400.S65B1C2E.COVIMV2.PARAMPF ([KEY],DATAI,DATAF)
VALUES('2','20070101','20070630')
"(Righe interessate: 1)"
Oggi l'informatica mi sorride
Cordialità
![ObiWan [MVP]'s profile photo](https://lh3.googleusercontent.com/a/default-user=s40-c)
ObiWan [MVP]
> INSERT AS400.S65B1C2E.COVIMV2.PARAMPF ([KEY],DATAI,DATAF)
> VALUES('2','20070101','20070630')
> "(Righe interessate: 1)"
a questo punto, se vuoi semplificarti la vita, creati una serie di
stored
per accedere ai dati AS (sia il lettura che in scrittura) ed usa queste
ultime al posto delle istruzioni SQL "secche", ci guadagnerai ;-)
tiriamoavanti
news:O6iuynn4...@TK2MSFTNGP02.phx.gbl...
Consiglio ottimo; nel mio caso però è 'na una roba tantum già completamente
isolata in una semplicissima SP...
Mi piacerebbe sapere perché/come il NOLOCK sulle read possa influenzare la
insert... bah!
Credo comunque che questo sia il problema che molti incontrano con le
scritture su as/400; giusto poco fa se n'è parlato qui.
ObiWan [MVP]
> influenzare la insert... bah!
non è solo il nolock (almeno per la mia esperienza personale) ma anche
l'esistenza (o meno) di un indice primario con chiave univoca, se manca
quello...
ciao
hyppos
Ecco appunto!
Su AS/400 abbiamo tutte file fisici senza chiavi primarie che di solito sono
costruite su viste con un gruppo di campi indicizzati e definiti UNIQUE,
quidi il problema è quello! Se voglio eseguire INSERT, UPDATE e DELETE lo
devo fare sulle viste allora?
hyppos
tiriamoavanti
news:48760725$0$40313$4faf...@reader5.news.tin.it...
Prova e facci sapere.
Io prima di mercoledì non posso testare, però ciò che dice ObiWan (uhmm nick
che sa di icrl) sounds...
ObiWan [MVP]
se per icrl intendi it.comp.reti.locali.. beh, si
è uno dei gruppi che frequento.. perchè ?
ObiWan [MVP]
> Io prima di mercoledì non posso testare, però ciò che dice ObiWan
(uhmm
> nick che sa di icrl) sounds...
since we're at it...
c'è da tenere presente un'altra cosuccia quando si lavora con
le tabelle su AS; normalmente quando su AS si crea una tabella
è necessario specificare la dimensione massima della stessa,
ora... esiste un flag che per default è *disabilitato* che indica al
sistema come gestire i records eliminati, con l'impostazione di
default, tali records NON vengono eliminati da una DELETE ma
solo "marcati come eliminati" (e non sono più visibili) e tali records
NON sono riutilizzati ma entrano nel conto dei records totali della
tabella; a questo punto... supponiamo di aver creato una tabella
con una capacità massima di 1000 records, la tabella raggiunge
ad un certo punto 999 records, noi però usando una "DELETE"
eliminiamo 100 records, quindi, fiduciosi che sia tutto ok facciamo
la INSERT di 10 records ... e di botto tutto apparentemente si "PIANTA"
se però andiamo alla console di AS scopriamo un messaggio in
attesa... che avverte che la tabella è piena :) !
Il fatto è che pur avendo eliminato quei 100 records, questi NON
sono stati fisicamente eliminati e comunque NON verranno
riutilizzati da AS, quindi il conteggio totale dei records contenuti
nella tabella resterà sempre 999 :) il che significa che l'INSERT
al superamento del limite stabilito per la tabella si "pianterà" dato
che il driver ODBC di AS resterà in attesa che qualcuno risponda
al messaggio :D
In questi casi è necessario fare attenzione al dimensionamento
massimo delle tabelle, oppure impostare il flag in modo che venga
abilitato il riutilizzo dei records, in tal caso, nello scenario visto
sopra
le insert sarebbero andate a buon fine dato che i 10 records verranno
inseriti riscrivendo alcuni dei records precedentemente cancellati
ciaoooooooooo
hyppos
unique ma non funziona.
Ecco la risposta ad un DELETE:
OLE DB provider 'MSDASQL' could not delete from table
'"BELFAGOR"."TEST"."PIA400"'. There was a recoverable, provider-specific
error, such as an RPC failure.
[OLE/DB provider returned message: [IBM][iSeries Access ODBC Driver][DB2
UDB]SQL7008 - PIA400 in TEST non valido per l'operazione.]
OLE DB error trace [OLE/DB Provider 'MSDASQL' IRowsetChange::DeleteRows
returned 0x80040e21: DBROWSTATUS_E_FAIL].
ObiWan [MVP]
Driver][DB2
> UDB]SQL7008 - PIA400 in TEST non valido per l'operazione.]
e qui casca l'asino... sei sicuro che l'utente che usi per la
connessione ODBC abbia diritti di accesso in scrittura su
quella tabella ? Inoltre, se si tratta di una vista, quest'ultima
è aggiornabile ?
hyppos
aleatico, seduto ad un tavolino in ferro battuto del vecchio bar, pensando a
quanto fortunata fosse la mia vita quando udii ObiWan [MVP] profferire il
seguente verbo:
Si ad entrambe le domande.
Nel frattempo ho sottomesso a journal il file e le query hanno preso a
funzionare!
Eppure nelle prove senza journal avevo usato "SET TRANSACTION ISOLATION
LEVEL READ UNCOMMITTED" come indicato da tiriamoavanti.
Resta il problema della chiave: in un file creato per prova non mi fa
eseguire nè il DELETE nè l'UPDATE dandomi come errore "Informazioni sulla
colonna chiave insufficienti o errate. Troppe righe interessate
dall'aggiornamento"; la stessa istruzione (DELETE) eseguita su AS/400 da
Intercative Sql (STRSQL) funziona...
Mah...
ObiWan [MVP]
> "Informazioni sulla colonna chiave insufficienti o errate. Troppe
> righe interessate dall'aggiornamento";
mumble... cosa succede se provi (sto pensando ad alta voce) a
creare un indice (primario/univoco) sulla tabella del linked server
usando SQL server ?
hyppos
> creare un indice (primario/univoco) sulla tabella del linked server
> usando SQL server ?
Il costrutto TSQL è diverso da quello DB400 e non funziona su una tabella
DB400 collegata, probabilmente perche il provider non riesce a convertire
l'istruzione TSQL nell'equivalente DB400.
Ad esempio su DB400 se voglio recuperare i primi 100 record devo scrivere
SELECT
*
FROM
LIB.FILE
FETCH FIRST 100 ROWS ONLY
perché la clausola TOP non esiste.
Però se scrivo una query TSQL del tipo
SELECT TOP 100
*
FROM
AS400.SCHEMA.LIB.FILE
sun una tabella DB400 collegata, funziona perfettamente.
hyppos
tiriamoavanti
"ObiWan [MVP]" <obi...@mvps.org> ha scritto nel messaggio
news:eUogGzp4...@TK2MSFTNGP04.phx.gbl...
> le tabelle su AS; normalmente quando su AS si crea una tabella
> è necessario specificare la dimensione massima della stessa,
> ora...
sono d'avanti all'AS e devo dire che funziona alla grande: riassunto:
AS/400
file fisico (senza view) con size(*nomax) e indice sul fisico (surrogata, di
1 campo)
SQLServer 2000
linked server con MS OLEDB per ODBC (prodotto=seriale AS)
ODBC con driver IBM client access (ricordarsi il dsn sul server :))
Utente qpgmr (un forte, al di sopra di ogni sospetto!)
Istruzioni precedute da un bel "unlock" nella forma SET TRANSACTION
ISOLATION LEVEL READ UNCOMMITTED
Così non ho avuto problemi sia in inserimento.
Successivamente mi sono accorto di aver creato solo un indice e non una PK
univoca; la delete in questo caso funziona solo se non ci sono fisicamente
chiavi duplicate nei record, se/quando succede si pianta!
Mi sono anche accorto che i comandi "puri" AS generano un qualche livello
d'errore sul percorso; non ho indagato e vi passo solamente un esempio:
CLRPFM e da quel momento la delete in TSQL inizia a protestare!
[Scusare l'orribile forma, ho tempo zero :(]
P.S. ho avuto anche una serie di problemi di insert che non capivo... poi ho
corretto gli errori nel programma! Così, per dire che a volte non è colpa
dell'AS :)
p.p.s. si obiwan ricordavo l'account dal ng delle reti perché ho sempre
apprezzato le tue risposte
hyppos
> Istruzioni precedute da un bel "unlock" nella forma SET TRANSACTION
> ISOLATION LEVEL READ UNCOMMITTED
Resta da capire perché a me non funziona e devo per forza mettere il file
AS/400 sotto journal se voglio modificare i dati...
Grazie per le info.
hyppos
tiriamoavanti
news:487dcc5b$0$1083$4faf...@reader2.news.tin.it...
>
>
> Resta da capire perché a me non funziona e devo per forza mettere il file
> AS/400 sotto journal se voglio modificare i dati...
Non sono riuscito a farmene un'idea, sorry.
Dell'ipotesi di obiwan sull'utente "paralitico" cosa ne dici?
Un'altra cosa; lavoravo con SSSM su istanza v8. Detto ciò (che non so se
c'entri :)) devo sottolineare che ho avuto degli errori (sempre di quelli
incomprensibili del driver) che mi hanno fatto il piacere di scomparire
semplicemente chiudendo e riaprendo sssm...
Lo so, assomiglia ad un rito vodoo, ma giuro non ho usato né galline né
vergini :)
hyppos
> Dell'ipotesi di obiwan sull'utente "paralitico" cosa ne dici?
Ho provato con un utente con privilegi *SECOFR ma non cambia niente.
Unica differenza č che io l'utente 400 (user e password) l'ho settato nella
Tab "Security" del linked server su Sql Server.
> Un'altra cosa; lavoravo con SSSM su istanza v8.
Cioč?
tiriamoavanti
>
> Ho provato con un utente con privilegi *SECOFR ma non cambia niente.
> Unica differenza č che io l'utente 400 (user e password) l'ho settato
> nella Tab "Security" del linked server su Sql Server.
Non sono in grado di dirti le differenze; io abituato all'emulazione
terminale non mi sono posto il problema ed ho messo utente/passwd tra i
parametri del driver odbc del client access.
In Security del linked server non ho messo nulla; ho lasciato il default.
>> Un'altra cosa; lavoravo con SSSM su istanza v8.
> Cioč?
che forse con la 2005 avrebbe potuto non darmi l'errore... non so; volevo
solo sottolinare che ero su un 2000