sto migrando le mie dts da SQL Server 2000 a SQL Server 2005.
L'intenzione è quella di farle diventare dtsx con SSIS.
La maggior parte scaricano da AS400 in Sql Server.
Ho notato un problema.
Non riesco a definire un sorgente ODBC Iseries As400 come facevo con
la precedente versione di SQL SERVER 2000.
Ho intallato IBM Iseries OLEDB,ODBC,.NET.
Se uso IBM OLE DB ho notato che non risponde veloce come il vecchio
ODBC.
Ho letto su internet che consigliano il driver Microsoft OLEDB for DB2
ma avendo la versione Standard di SqlServer 2005 non posso usarlo.
Qualcuno mi sa dire perchè non riesco?
L'alternativa è acquistare i driver della HIT SOFTWARE che pare
funzionino benone.
GRAZIE
> sto migrando le mie dts da SQL Server 2000 a SQL Server 2005.
> L'intenzione � quella di farle diventare dtsx con SSIS.
> La maggior parte scaricano da AS400 in Sql Server.
>
> Ho notato un problema.
Ha ha ha, ben ti sta! :-P
Scusa ma, sai com'�, mal comune...
> Non riesco a definire un sorgente ODBC Iseries As400 come facevo con
> la precedente versione di SQL SERVER 2000.
Le mie connessioni OLEDB ad AS400/iSeries sono configurate cos�:
- provider = "IBM DB2 UDB for iSeries IBMDASQL OLE DB provider", fornito
con l'iSeries Access (V5R3);
- nome utente e password inseriti e flag di spunta su "Consenti
salvataggio password";
- catalogo iniziale = nome del database su DB2 (il mio � qualcosa di
simile a "S123456D").
Come origine dati, uso la modalit� "Comando SQL" e scrivo l'istruzione
con il linguaggio del DB2. Questo significa che ad esempio posso usare
la funzione TRIM che non ha una corrispondente in t-sql (ok, si pu� fare
LTRIM(RTRIM(stringa))).
> Ho intallato IBM Iseries OLEDB,ODBC,.NET.
> Se uso IBM OLE DB ho notato che non risponde veloce come il vecchio
> ODBC.
Guarda, ti do un consiglio con tutto il cuore: lascia perdere!!
A me hanno fatto fare quasi un disastro. A parte la lentezza, che � una
cosa improponibile, la cosa pi� grave � che mi sono trovato con le
attivit� 'flusso di dati' che davano esito positivo ma i dati non erano
stati copiati... ma non sempre, altrimenti sarebbe stato troppo bello.
Dopo l'esperienza fatta, non li userei nemmeno se fossi costretto.
> Ho letto su internet che consigliano il driver Microsoft OLEDB for DB2
> ma avendo la versione Standard di SqlServer 2005 non posso usarlo.
Esatto.
Avevo provato pure io ad usarli, nella versione Developer, ma
sinceramente non sono mai riuscito a farli funzionare. Un sacco di
messaggi criptici e informazioni online praticamente introvabili...
anche in questo caso, meglio lasciar perdere!
> L'alternativa � acquistare i driver della HIT SOFTWARE che pare
> funzionino benone.
Cos� s� dice, quindi direi che questa � la soluzione estrema.
Secondo me, se devi prendere dati e non inserirne, puoi tranquillamente
evitare i driver a pagamento.
A dire il vero, anche se uso SSIS 2005 e 2008, per scrivere direttamente
su AS400 utilizzo ancora i meravigliosi DTS con la loro origine dati
ODBC, visto che comunque puoi far girare dei DTS dentro i SSIS.
--
David Martin
Quindi se ho capito bene tu usi l'OLEDB di IBM.
Lo uso anch'io.....ma non hai notato una lentezza incredibile rispetto
al vecchio ODBC?
Mi sembra di aver capito che anzichè migrare le dts vecchie le hai
tirare dentro SQL SERVER 2005 mantenendo il formato 2000?
Grazie
On 11 Mag, 14:42, David Martin <david.mar...@libero.it> wrote:
> On 05/11/2010 02:12 PM, Teo wrote:
>
> > sto migrando le mie dts da SQL Server 2000 a SQL Server 2005.
> > L'intenzione è quella di farle diventare dtsx con SSIS.
> > La maggior parte scaricano da AS400 in Sql Server.
>
> > Ho notato un problema.
>
> Ha ha ha, ben ti sta! :-P
> Scusa ma, sai com'è, mal comune...
>
> > Non riesco a definire un sorgente ODBC Iseries As400 come facevo con
> > la precedente versione di SQL SERVER 2000.
>
> Le mie connessioni OLEDB ad AS400/iSeries sono configurate così:
> - provider = "IBM DB2 UDB for iSeries IBMDASQL OLE DB provider", fornito
> con l'iSeries Access (V5R3);
> - nome utente e password inseriti e flag di spunta su "Consenti
> salvataggio password";
> - catalogo iniziale = nome del database su DB2 (il mio è qualcosa di
> simile a "S123456D").
>
> Come origine dati, uso la modalità "Comando SQL" e scrivo l'istruzione
> con il linguaggio del DB2. Questo significa che ad esempio posso usare
> la funzione TRIM che non ha una corrispondente in t-sql (ok, si può fare
> LTRIM(RTRIM(stringa))).
>
> > Ho intallato IBM Iseries OLEDB,ODBC,.NET.
> > Se uso IBM OLE DB ho notato che non risponde veloce come il vecchio
> > ODBC.
>
> Guarda, ti do un consiglio con tutto il cuore: lascia perdere!!
> A me hanno fatto fare quasi un disastro. A parte la lentezza, che è una
> cosa improponibile, la cosa più grave è che mi sono trovato con le
> attività 'flusso di dati' che davano esito positivo ma i dati non erano
> stati copiati... ma non sempre, altrimenti sarebbe stato troppo bello.
>
> Dopo l'esperienza fatta, non li userei nemmeno se fossi costretto.
>
> > Ho letto su internet che consigliano il driver Microsoft OLEDB for DB2
> > ma avendo la versione Standard di SqlServer 2005 non posso usarlo.
>
> Esatto.
> Avevo provato pure io ad usarli, nella versione Developer, ma
> sinceramente non sono mai riuscito a farli funzionare. Un sacco di
> messaggi criptici e informazioni online praticamente introvabili...
> anche in questo caso, meglio lasciar perdere!
>
> > L'alternativa è acquistare i driver della HIT SOFTWARE che pare
> > funzionino benone.
>
> Così sì dice, quindi direi che questa è la soluzione estrema.
> Quindi se ho capito bene tu usi l'OLEDB di IBM.
Uso un misto fra OLEDB e ODBC.
Uso ODBC quando AS400/iSeries � la destinazione, uso OLEDB quando �
l'origine. Ma non c'� una vera motivazione per cui ho fatto cos�... o
meglio, la motivazione c'�: avevo configurato tutto con OLEDB, ma poi
quando ho testato i pacchetti e visto le prestazioni e l'affidabilit� di
OLEDB, sono corso ai ripari e ho fatto un mezzo passo indietro.
Perch� l'ho fatto solo quando AS400/iSeries � la destinazione?
Sostanzialmente per due motivi:
1. perch� quando AS400/iSeries � l'origine dei dati, non ho notato
particolari problemi e/o rallentamenti;
2. perch� le mie connessioni sono sempre soggette a file di
configurazione (nel quale gli dico di volta in volta a quale server
collegarsi, quali credenziali usare, ecc.), e questo non funziona con le
connessioni presenti dentro le attivit� "Esegui pacchetto DTS".
> Lo uso anch'io.....ma non hai notato una lentezza incredibile rispetto
> al vecchio ODBC?
Una differenza abissale. Non so se hai provato in scrittura... in
lettura tutto sommato a me � parso decente, in scrittura � una cosa che
dovrebbe farli vergognare.
> Mi sembra di aver capito che anzich� migrare le dts vecchie le hai
> tirare dentro SQL SERVER 2005 mantenendo il formato 2000?
S�, ci piazzo dentro l'attivit� "Esegui pacchetto DTS".
L'unico problema � che se ad esempio hai un sistema a 64 bit, non c'�
supporto alla progettazione DTS, quindi io mi sono fatto una bella vm
con Windows 2000 e tutto funziona a meraviglia.
--
David Martin
Non capisco ancora una cosa......scusami ma sono tardo...
Tu usi anche ODBC .....invece io pur avendolo installato dal cd
iSeries non riesco ad utilizzarlo.Mi spiego meglio.
Se creo un progetto SSIS non ho dei componenti Source che si aspettano
ODBC ma solo OLEDB ( a parte ADO con DATAREADER) mentre se uso il
wizard (tasto destro su un db e poi importa)
non vedo nessuna voce (come nel 2000) iSeries ODBC o Client Access IBM
ma forse l'unica è .Net for ODBC.
Tu quando usi ODBC come lo usi?
Grazie
On 11 Mag, 15:31, David Martin <david.mar...@libero.it> wrote:
> On 05/11/2010 03:04 PM, Teo wrote:
>
> > Quindi se ho capito bene tu usi l'OLEDB di IBM.
>
> Uso un misto fra OLEDB e ODBC.
> Uso ODBC quando AS400/iSeries è la destinazione, uso OLEDB quando è
> l'origine. Ma non c'è una vera motivazione per cui ho fatto così... o
> meglio, la motivazione c'è: avevo configurato tutto con OLEDB, ma poi
> quando ho testato i pacchetti e visto le prestazioni e l'affidabilità di
> OLEDB, sono corso ai ripari e ho fatto un mezzo passo indietro.
>
> Perché l'ho fatto solo quando AS400/iSeries è la destinazione?
> Sostanzialmente per due motivi:
> 1. perché quando AS400/iSeries è l'origine dei dati, non ho notato
> particolari problemi e/o rallentamenti;
> 2. perché le mie connessioni sono sempre soggette a file di
> configurazione (nel quale gli dico di volta in volta a quale server
> collegarsi, quali credenziali usare, ecc.), e questo non funziona con le
> connessioni presenti dentro le attività "Esegui pacchetto DTS".
>
> > Lo uso anch'io.....ma non hai notato una lentezza incredibile rispetto
> > al vecchio ODBC?
>
> Una differenza abissale. Non so se hai provato in scrittura... in
> lettura tutto sommato a me è parso decente, in scrittura è una cosa che
> dovrebbe farli vergognare.
>
> > Mi sembra di aver capito che anzichè migrare le dts vecchie le hai
> > tirare dentro SQL SERVER 2005 mantenendo il formato 2000?
>
> Sì, ci piazzo dentro l'attività "Esegui pacchetto DTS".
> L'unico problema è che se ad esempio hai un sistema a 64 bit, non c'è
> Tu quando usi ODBC come lo usi?
Solo ed esclusivamente dentro i DTS.
--
David Martin
Non lo so.
Forse per lo stesso motivo per cui MS ha deciso di chiudere tutti i ng
pubblici, questo incluso...
--
David Martin
> I dati numerico contengono spazi e altri caratteri sporchi che il
> vecchio rpg (trattandoi file in modo sequenziale) riesce a gestire.
> Tutte le query su qui campi danno come risultato "data conversion
> mapping error".
Scusa, ma non puoi castare il dato a stringa e poi farci un subtring,
prendendo solo la parte che ti interessa?
--
David Martin
>> Scusa, ma non puoi castare il dato a stringa e poi farci un subtring,
>> prendendo solo la parte che ti interessa?
>>
> Purtroppo il cast non funge perch� ovviamente se un campo � dichiarato
> decimal(5,0) non pu� aspettarsi di certo un carattere alfanumerico o un
> blank e quindi "data conversion mapping error"
C'� qualcosa che mi sfugge.
Se in AS400 i dati sono dichiarati come decimal, come fanno ad esserci
dei caratteri alfanumerici? Per quanto i programmatori rpg siano
fantasiosi, non possono bypassare i controlli del motore del db.
Oltre a questo, dove ti da il messaggio di errore "data conversion
mapping error"?
--
David Martin
ad un certo punto posso avere l'arbitrariet� di deciderec che il campo
descr che va dalla posizione 78 alla 85 diventi decimal senza nessun
problema.
Oltre a mancare completamente il concetto di dataset (tutto viene visto
diciamo come logica di cursori), manca anche il concetto di dizionario
dati solido.
Ti dir� di peggio il primo carattere determina anche il tipo di
tracciato record! Follia! Ovvero un file pu� alloggiare pi� tracciati
record, tradotto in sql tante create table contemporanee per una sola
table!!
> Oltre a questo, dove ti da il messaggio di errore "data conversion
> mapping error"?
>
>
E' l'errore nativo restituito tanto nelle connessioni odbc quanto in
quelle ole db, e nel monitor dei lavori su as400.
Sorpreso?
Daniele
Ormai siamo OT, ma tanto fra un po' chiudono il ng, quindi godiamoci il
tempo che ci resta :-D
> Ecco come fanno. Questo � il file degli articoli
> MGA4FM AA 1 C1
> 2 3 DITTA
> 4 5 VTEST
> 4 16 ARTI
> 17 24 SIG
> 25 370VRIEAN
> 38 77 DESCR
> 78 85 SIGLA
> 86 115 DESSU
> 116 1280CODEAN
> 129 130 UMB
> 131 132 UMS
> 133 142 YCOEFF
> 143 143 OBBUMS
> 144 145 UMV
> 146 160 YCOEFV
> 161 1620IVA
>
> ad un certo punto posso avere l'arbitrariet� di deciderec che il campo
> descr che va dalla posizione 78 alla 85 diventi decimal senza nessun
> problema.
Proprio non riesco a capire. Un'istruzione di questo tipo
---
SELECT SUBSTRING(nome_campo, 78, 8) AS mia_descrizione FROM libreria.file
---
ti restituir� sempre lo stesso tipo di dati, ad esempio nchar(8). No?
Non capisco il concetto di "posso avere l'arbitrariet� di decidere che
il campo descr che va dalla posizione 78 alla 85 diventi decimal"...
Per poter scrivere nel database sia numeri che lettere, evidentemente
avranno definito una sola colonna enorme di tipo nchar. Ci siamo?
> Ti dir� di peggio il primo carattere determina anche il tipo di
> tracciato record!
Ok, ma se conosci questa informazione, tu puoi modificare l'istruzione
sql a seconda di quel primo carattere.
> Sorpreso?
Solo poco poco... non ne ho visti tanti di personaggi che lavorano su
quelle piattaforme, ma quei pochi sono indietro di venti anni.
--
David Martin
>> Ti dir� di peggio il primo carattere determina anche il tipo di
>> tracciato record!
>>
> Ok, ma se conosci questa informazione, tu puoi modificare l'istruzione
> sql a seconda di quel primo carattere.
>
>
>
Come sopra.
>> Sorpreso?
>>
> Solo poco poco... non ne ho visti tanti di personaggi che lavorano su
> quelle piattaforme, ma quei pochi sono indietro di venti anni.
>
>
Eppure lo sai che hanno clienti importanti!
Tanto gli fanno comprare server da capogiro e cos� risolvono i problemi
di prestazioni.
Infatti il tuning � quasi inesistente.
Ciao
Daniele
Nel fratttempo qualcuno di voi potrebbe indicarmi qualche sito dove
spiegano il discorso della sicurezza delle dtsx.
Non ho capito molto bene come funziona....so solo che se creo una dtsx
in debug funziona mentre se la importo e schedulo nell'agent di Sql mi
dice password mancante.
Grazie
On 12 Mag, 09:23, OneEDP <OneEDP@antispam> wrote:
> Il 11/05/2010 19.44, David Martin ha scritto:
>
>
>
> > On 05/11/2010 06:41 PM, OneEDP wrote:
>
> > Ormai siamo OT, ma tanto fra un po' chiudono il ng, quindi godiamoci il
> > tempo che ci resta :-D
>
> Brutta storia!
>
> >> Ecco come fanno. Questo è il file degli articoli
> >> MGA4FM AA 1 C1
> >> 2 3 DITTA
> >> 4 5 VTEST
> >> 4 16 ARTI
> >> 17 24 SIG
> >> 25 370VRIEAN
> >> 38 77 DESCR
> >> 78 85 SIGLA
> >> 86 115 DESSU
> >> 116 1280CODEAN
> >> 129 130 UMB
> >> 131 132 UMS
> >> 133 142 YCOEFF
> >> 143 143 OBBUMS
> >> 144 145 UMV
> >> 146 160 YCOEFV
> >> 161 1620IVA
>
> >> ad un certo punto posso avere l'arbitrarietà di deciderec che il campo
> >> descr che va dalla posizione 78 alla 85 diventi decimal senza nessun
> >> problema.
>
> > Proprio non riesco a capire. Un'istruzione di questo tipo
> > ---
> > SELECT SUBSTRING(nome_campo, 78, 8) AS mia_descrizione FROM libreria.file
> > ---
> > ti restituirà sempre lo stesso tipo di dati, ad esempio nchar(8). No?
>
> > Non capisco il concetto di "posso avere l'arbitrarietà di decidere che
> > il campo descr che va dalla posizione 78 alla 85 diventi decimal"...
> > Per poter scrivere nel database sia numeri che lettere, evidentemente
> > avranno definito una sola colonna enorme di tipo nchar. Ci siamo?
>
> In pratica quello che fanno i programmatori rpg è quello di avere
> un'unica enorme colonna e poi di spezzetarla all'interno di tutti i
> programmini dichiarando sempre le posizioni per loro significative, come
> si si trattasse di una stringa unica da spalmare nei vari campi.
> Ecco perché rpg riesce ad infisciarsene se in una determinata posizione
> della stringa c'è un numero piuttosto che una lettera. Tanto si
> eccepisce l'errore e si azzera e chissenefrega.
> Ovviamente per un db un approccio del genere è disastroso.
> Infatti le tabelle in qualche modo hanno una struttura visibile con i
> loro campi, mentre in rpg la struttura viene ricreata a piacere. In ole
> db, come in odbc i metadati ottengono le info di tutte le colonne, ma se
> i dati in essi contenuti contengono liquami... c'è poco da fare.
>
> >> Ti dirò di peggio il primo carattere determina anche il tipo di
> >> tracciato record!
>
> > Ok, ma se conosci questa informazione, tu puoi modificare l'istruzione
> > sql a seconda di quel primo carattere.
>
> Come sopra.
> >> Sorpreso?
>
> > Solo poco poco... non ne ho visti tanti di personaggi che lavorano su
> > quelle piattaforme, ma quei pochi sono indietro di venti anni.
>
> Eppure lo sai che hanno clienti importanti!
> Tanto gli fanno comprare server da capogiro e così risolvono i problemi
> di prestazioni.
> Infatti il tuning è quasi inesistente.
> Ciao
> Daniele- Nascondi testo citato
>
> - Mostra testo citato -
> Nel fratttempo qualcuno di voi potrebbe indicarmi qualche sito dove
> spiegano il discorso della sicurezza delle dtsx.
> Non ho capito molto bene come funziona....so solo che se creo una dtsx
> in debug funziona mentre se la importo e schedulo nell'agent di Sql mi
> dice password mancante.
Se cominci a quotare un po' meglio, forse ti aiuto :-)
Io ti sconsiglio di andare a chiedere nel ng di AS400, perch� non � una
cosa che dipende da AS400/iSeries.
Nelle propriet� del pacchetto, la propriet� "Protection Level" come �
impostata?
Se metti "DontSaveSensisitve", tutti i dati relativi a username/password
delle connessioni sono perse.
Il mio consiglio spassionato � di continuare ad usare i DTS, quando hai
a che fare con AS400/iSeries, perch� anche usando OLEDB, configurazioni
e simili, io ho comunque delle cose che non funzionano a dovere...
--
David Martin
Semplicemente vorrei che si comportassero come le vecchie dts perchè
il server è solo interno e non accessibile da internet.
La dtsx è creata con un utente che ho le stesso con il quale è
startato il servizio Agent di Sql.
Ho letto che si potrebbero usare utenze proxy,credenziali oppure file
di configurazione......ma non conosco il loro funzionamento.....nella
versione 2000 non erano presenti.
Se mi indicate qualche sito interessante mi documento un po'....non
vorrei abusare della vostra disponibilità
Grazie
On 12 Mag, 12:23, David Martin <david.mar...@libero.it> wrote:
> On 05/12/2010 11:53 AM, Teo wrote:
>
> > Nel fratttempo qualcuno di voi potrebbe indicarmi qualche sito dove
> > spiegano il discorso della sicurezza delle dtsx.
> > Non ho capito molto bene come funziona....so solo che se creo una dtsx
> > in debug funziona mentre se la importo e schedulo nell'agent di Sql mi
> > dice password mancante.
>
> Se cominci a quotare un po' meglio, forse ti aiuto :-)
>
> Io ti sconsiglio di andare a chiedere nel ng di AS400, perché non è una
> cosa che dipende da AS400/iSeries.
>
> Nelle proprietà del pacchetto, la proprietà "Protection Level" come è
> impostata?
> Se metti "DontSaveSensisitve", tutti i dati relativi a username/password
> delle connessioni sono perse.
>
> Il mio consiglio spassionato è di continuare ad usare i DTS, quando hai
> a che fare con AS400/iSeries, perché anche usando OLEDB, configurazioni
> On 12 Mag, 12:23, David Martin<david.mar...@libero.it> wrote:
>
>> On 05/12/2010 11:53 AM, Teo wrote:
>>
>>
>>> Nel fratttempo qualcuno di voi potrebbe indicarmi qualche sito dove
>>> spiegano il discorso della sicurezza delle dtsx.
>>> Non ho capito molto bene come funziona....so solo che se creo una dtsx
>>> in debug funziona mentre se la importo e schedulo nell'agent di Sql mi
>>> dice password mancante.
>>>
>> Se cominci a quotare un po' meglio, forse ti aiuto :-)
>>
>> Io ti sconsiglio di andare a chiedere nel ng di AS400, perch� non � una
>> cosa che dipende da AS400/iSeries.
>>
>> Nelle propriet� del pacchetto, la propriet� "Protection Level" come �
>> impostata?
>> Se metti "DontSaveSensisitve", tutti i dati relativi a username/password
>> delle connessioni sono perse.
>>
>> Il mio consiglio spassionato � di continuare ad usare i DTS, quando hai
>> a che fare con AS400/iSeries, perch� anche usando OLEDB, configurazioni
> Come ti dicevo nello stesso ng trovi "remote access" o gi� di l� per
> fare in modo che un pc faccia da gateway su as400, non ricordo bene.
Non ho capito a cosa gli possa servire una cosa del genere...
--
David Martin
On 12 Mag, 14:01, David Martin <david.mar...@libero.it> wrote:
> On 05/12/2010 12:50 PM, OneEDP wrote:
>
> > Come ti dicevo nello stesso ng trovi "remote access" o giù di lì per
Vengono rimosse se tu imposti il "ProtectionLevel" a "DontSaveSensisitvie".
Se usi ad esempio il livello "EncryptSensitiveWithPassword", sta
tranquillo che i dati di accesso non vanno persi... solo che quando vuoi
eseguire il pacchetto, gli devi fornire la password.
> Semplicemente vorrei che si comportassero come le vecchie dts perch�
> il server � solo interno e non accessibile da internet.
Vuoi che si comportino come i vecchi DTS?
Ripeto, per l'ultima volta, che se vuoi che funzionino come i DTS,
nessuno ti vieta di continuare ad usarli. Crei un pacchetto SSIS e ci
metti dentro tutte le attivit� che vuoi, ma la parte di 'flusso dati' la
fai con i DTS.
> Ho letto che si potrebbero usare utenze proxy,credenziali oppure file
> di configurazione......ma non conosco il loro funzionamento.....nella
> versione 2000 non erano presenti.
I file di configurazione sono una cosa molto carina, ma prima devi
leggere come si usano, fare le tue prove e poi eventualmente torni qui a
chiedere.
> Se mi indicate qualche sito interessante mi documento un po'....non
> vorrei abusare della vostra disponibilit�
Guarda, trovi gi� tutto nei BOL.
--
David Martin
>>>> Come ti dicevo nello stesso ng trovi "remote access" o gi� di l� per
>>>> fare in modo che un pc faccia da gateway su as400, non ricordo bene.
>>>>
>>> Non ho capito a cosa gli possa servire una cosa del genere...
>>
> Allora siamo in tre a non capire :-)
Ma il problema � che sei stato tu a scrivere la frase incriminata :-)
---
Come ti dicevo nello stesso ng trovi "remote access" o gi� di l� per
fare in modo che un pc faccia da gateway su as400, non ricordo bene.
---
--
David Martin