Discussion :

[bridaine]

Bonjour,

Je modifie une application SQL Server 2005 qui alimente un datawarehouse à partir de fichiers logs applicatifs.

J'ai une boucle de chargement par For Each Loop qui inclut un traitement dans le Data Flow.

Les faibles performances de SSIS au niveau des séparateurs m'obligent à saisir des lignes complètes sans séparateurs (la séparation est effectuée par des scripts VB). Ceci fonctionnait très bien jusque là avec les anciens logs.

Avec les nouveaux logs, j'obtiens le message

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
An error occurred while processing file "D:\LOG_PARSER\MAG_SRC_LOG\serverlog\40app_exploit-mag-bdbctserverlogconfig_110911.log" on data row 1.

Notez qu'après "row 1" apparaissent deux carrés qui symbolisent sans doute

1. soit des caractères pourris
2. soit fin de ligne associé à retour chariot

Je n'ai rien d'autre comme information, aucun moyen de tracer
le contenu de la ligne qui pose problème
la position exacte de la ligne incriminée (le chiffre 1 ne veut rien dire puisque la ligne 1 passe très bien seule ou dans un paquet restreint)

Que faire ?

Merci beaucoup

[elsuket]

Bonjour,

Notez qu'après "row 1" apparaissent deux carrés qui symbolisent sans doute

soit des caractères pourris
soit fin de ligne associé à retour chariot

Ou bien des caractères Unicode, que notepad (si c'est bien l'application avec laquelle vous avez vu les carrés) ne sait pas interpréter, à moins, je crois, que le fichier soit sauvegardé en Unicode.

Le premier enregistrement de votre fichier contient-il ces carrés ?

@++

[iberserk]

Les faibles performances de SSIS au niveau des séparateurs m'obligent à saisir des lignes complètes sans séparateurs

Ca ca me fera toujours mourir de rire...

Vous n'avez pas du tester beaucoup SSIS pour avancer ce genre d'ignominie...

[SQLpro]

Ca ca me fera toujours mourir de rire...

Vous n'avez pas du tester beaucoup SSIS pour avancer ce genre d'ignominie...

C'est vrai que insérer 1 To de données via SSIS en 30 minutes, c'est quand même un peu léger !!!

http://msdn.microsoft.com/en-us/libr...ql.100%29.aspx

A +

[iberserk]

SQLPRO, vous savez bien qu'avec un bon pattern vous pouvez faire beaucoups mieu en CSHARP avec LINQ TO ENTITIES...

[SQLpro]

T'as pas honte de poster des trucs comme ça, j'ai faillit vôôôôôôôôômir mon Kfé !

[Ptit_Dje]

Je n'ai rien d'autre comme information, aucun moyen de tracer
le contenu de la ligne qui pose problème
la position exacte de la ligne incriminée (le chiffre 1 ne veut rien dire puisque la ligne 1 passe très bien seule ou dans un paquet restreint)

Avez vous teste les data viewers ?

[bridaine]

Bonjour

Un grand merci à ceux d'entre vous qui ont pris la peine d'analyser ma demande et d'y répondre favorablement.

Le problème est momentanément résolu par un simple copier coller dans un nouveau fichier ce qui supprime les caractères non acceptés (si le message avait pu être plus précis...et le Data Viewer n'a rien écrit).

Maintenant il va falloir trouver une solution pour que les fichiers chargés automatiquement soient valides en entrée, ça c'est une autre histoire !
S'il y a 100 fichiers plats, je ne vais pas les recopier un à un

Enfin pour répondre à mon détracteur, il suffit de rappeler qu'EXCEL autant que SSIS traite les séparateurs sauf que :

• EXCEL propose une case libre "Autres" permettant de spécifier son propre séparateur, ce n'est pas le cas sur SSIS
• si EXCEL et SSIS formatent les colonnes avec le nombre maximal de séparateurs, EXCEL complète les colonnes vides par des colonnes à blanc alors que SSIS vient fourrer les lignes suivantes en guise de colonnes de complément sans tenir compte des fins de ligne qui ont pourtant été définies et le résultat devient aberrant (constaté il y a deux ans)

Malheureusement, on ne peut pas utiliser EXCEL pour ce genre d'application.

Voilà entre autres joyeusetés le genre de bug que l'on peut rencontrer sur un produit certes performant mais qui aurait mérité une finition un plus soignée (rappel concernant le constructeur : 5000 bugs répertoriés sur la version la plus performante de Windows XP, je cite un expert du CNAM aujourd'hui retraité mais qui est toujours consultant pour THALES, EDF et le Ministère de la Défense, excusez du peu)

Je ne me prétends pas un cador mais j'ai au moins la politesse de respecter mes interlocuteurs, cela fait partie de mon éducation de simple fils d'ouvrier

Quant à CSHARP et autres, je ne suis pas DSI et donc ne peux utiliser que les outils mis à ma disposition

[iberserk]

SQLPRO, vous savez bien qu'avec un bon pattern vous pouvez faire beaucoups mieu en CSHARP avec LINQ TO ENTITIES...

Quant à CSHARP et autres, je ne suis pas DSI et donc ne peux utiliser que les outils mis à ma disposition

Non mais c'était ironique le coups de LINQ TO ENTITIES

[SQLpro]

Enfin pour répondre à mon détracteur, il suffit de rappeler qu'EXCEL autant que SSIS traite les séparateurs sauf que :

• EXCEL propose une case libre "Autres" permettant de spécifier son propre séparateur, ce n'est pas le cas sur SSIS
• si EXCEL et SSIS formatent les colonnes avec le nombre maximal de séparateurs, EXCEL complète les colonnes vides par des colonnes à blanc alors que SSIS vient fourrer les lignes suivantes en guise de colonnes de complément sans tenir compte des fins de ligne qui ont pourtant été définies et le résultat devient aberrant (constaté il y a deux ans)

Ce que vous dite est faux :
1) on peut utiliser n'importe quel séparateur de champs et dilimiteur de ligne sous SSIS !
2) de même on peut choisir le mode de complétion, y compris chiane vide = NULL

Voilà entre autres joyeusetés le genre de bug que l'on peut rencontrer sur un produit certes performant mais qui aurait mérité une finition un plus soignée (rappel concernant le constructeur : 5000 bugs répertoriés sur la version la plus performante de Windows XP, je cite un expert du CNAM aujourd'hui retraité mais qui est toujours consultant pour THALES, EDF et le Ministère de la Défense, excusez du peu)

Et là, cela s'apparente à de la diffamation !
1) vous confondez visiblement bug et votre propre incompétence
2) lorsque l'on cite, on poste les références...

CONCLUSION :
Commencez par vous former à SSIS parce que là vous faites perdre du temps à ceux qui pourrait vous aider en sus de raconter d'énormes âneries !

A +

[zinzineti]

Maintenant il va falloir trouver une solution pour que les fichiers chargés automatiquement soient valides en entrée, ça c'est une autre histoire !
S'il y a 100 fichiers plats, je ne vais pas les recopier un à un

Regarde si tu peux utiliser BULK INSERT avec les fichiers de format (.fmt)

voici un lien

Pour des projets d'import/export de données j'utilise soit BCP ou BULK INSERT

A+