Discussion :

[Slaveak]

Bonjour à toutes et tous,

Depuis quelques temps j'ai cette erreur ci : "Une exception de type 'System.OutOfMemoryException' a été levée." très souvent quand je tente d'enregistrer mon projet.

Est-ce que quelqu'un connait la cause exacte de cette erreur ? Comment la régler ?

Contexte :
- Windows Server 2012.
- SQL Server 2012.
- Visual Studio 2010.

Je crois supposer que cela viendrait du fait que VS 2010 est en 32 bits, et donc n'utilise pas assez de RAM et que ça pose problème sur mon projet qui compte un grand nombre de package.

Détail du message d'erreur :

Erreur d'enregistrement du package. (Microsoft Visual Studio)

------------------------------
Emplacement du programme*:

à Microsoft.DataTransformationServices.Design.Serialization.DtrDesignerSerializer.SerializePackage(IDesignerSerializationManager manager, Package package, TextWriter textWriter)
à Microsoft.DataTransformationServices.Design.Serialization.DtrDesignerSerializer.SerializeComponent(IDesignerSerializationManager manager, IComponent component, Object serializationStream)
à Microsoft.DataWarehouse.Serialization.DesignerComponentSerializer.Serialize(IDesignerSerializationManager manager, Object value)
à Microsoft.DataWarehouse.VsIntegration.Designer.Serialization.DataWarehouseDesignerLoader.Serialize()
à Microsoft.DataWarehouse.VsIntegration.Designer.Serialization.BaseDesignerLoader.Flush(Boolean forceful)
à Microsoft.DataWarehouse.VsIntegration.Designer.Serialization.BaseDesignerLoader.Flush()
à Microsoft.DataWarehouse.VsIntegration.Designer.Serialization.DataWarehouseContainerManager.OnBeforeSave(UInt32 docCookie)

===================================

Une exception de type 'System.OutOfMemoryException' a été levée. (Microsoft.SqlServer.ManagedDTS)

------------------------------
Emplacement du programme*:

à System.String.CtorCharPtrStartLength(Char* ptr, Int32 startIndex, Int32 length)
à System.StubHelpers.BSTRMarshaler.ConvertToManaged(IntPtr bstr)
à Microsoft.SqlServer.Dts.Runtime.Package.SaveToXML(String& packageXml, IDTSEvents events)
à Microsoft.DataTransformationServices.Design.Serialization.DtrDesignerSerializer.SerializePackage(IDesignerSerializationManager manager, Package package, TextWriter textWriter)

[Elros]

Hello,

J'ai déjà eu ce genre d'erreur avec visual studio (version 64 bits) mais pour la partie SSRS (rapport trop volumineux).
Quand tu parles de beaucoup de package, tu en as combien ?

Développer avec la version 32 bits n'est pas affreux ? Temps long pour ouvrir un package (attente de validation des connexions...) ?

Elros

[Slaveak]

Bonjour Elros,

Alors en terme de nombre de package je suis à 101 packages utilisés.

Et pour VS en 32 bits, ah ben si c'est super chiant, il me faut entre 10 et 15 minutes pour ouvrir tous les packages. Et surtout je suis bien blasé par quand on a installé SQL Server 2012 en 64 bits, je pensais que tous les outils tiers suivraient en 64 bits aussi. Imagine ma déconvenue un coup où j'ai ouvert le gestionnaire des tâches pour constater que SSMS et SSIS étaient en 32 bits.

Donc un package à ouvrir ça va ... enfin pour les plus petits, mon plus gros c'est tout de suite une autre affaire. Et vu qu'en plus je lui en met ras la tronche, tu imagines bien qu'il plante régulièrement. Bim re 15 minutes que tous les packages se réouvrent.

la majorité je n'en ouvre que 2, 3 en même temps, mais pour la conversion de projet. il faut que je les ouvrent tous avant de pouvoir les déployer sur le serveur, et là rebelote, je sers les fesse que tout se passe bien ...

Enfin bref, belle aventure quoi !

Slaveak

[Elros]

Bonjour Slaveak,

Pour déployer tu n'as pas besoin d'ouvrir tous les packages ! Si tu as du versioning, un "get latest" (pour récupérer la dernière version de ton projet), un "build" (pour vérifier que ton projet est viable) et hop un "deploy" sur ton serveur dans "Integration Services Catalogs".

Je te conseil fortement à passer en version 64 bits tu gagneras du temps ! Et tu pourras le justifier facilement !
Les très gros packages prennent 15/20 secondes à se charger avant que je puisse naviguer dans la "Data flow".

Elros

[Invité]

Slaveak, de mon coté je ferme toujours les packages avant de fermer Visual Studio.
Comme ça, à la prochaine ouverture de la solution, tous les packages sont fermés; et je n'ouvre que les packages dont j'ai besoin (puis je les referme).

Autrement, si tous tes packages sont "ouverts en arrière-plan", quand tu vas vouloir déployer, Visual Studio va ouvrir chacun de tes packages en arrière plan, vérifier les connexions lors de la génération. Ca peut vite devenir horrible.
Comme le dit Elros, s'ils sont fermés, ils vont se générer puis déployer sans s'ouvrir.

[Slaveak]

Oui effectivement, maintenant c'est ce que je fais. Je ferme tous les packages avant de fermer Visual Studio.

Par contre Elros, tu me conseil de passer rapidement le 64 bit et je suis tout à fait de ton avis ! Par contre, comment je me débrouille ? je récupère VS 2016 ? Petit soucis... si il faut acheter une licence de VS, à mon avis je peux me brosser, mon client ne l'achètera pas... par contre je peux installer ce que je veux.

En ce qui concerne le déploiement, il est possible que je n'ai pas la bonne méthodologie (pour rappel, je suis autodidacte sur SSIS) que je fais à chaque fois que je veux déployer une nouvelle version de mon projet dans le catalogue SSIS de SQL Server
1. Je fais "Convertir le modèle de déploiement de projet" (Projet / Convertir le modèle de déploiement de projet )
2. Je Déploie (Projet / Déployer)

Et ceci à chaque fois.

Je crois supposer à ce que vous me dite tous les deux que, une fois fais la conversion, je n'ai plus à le faire si c'est juste une mise à jour de mon projet ?

Ah et Oui avec SQL Server 2012, dans mes souvenirs, il gère la version de projet.

En tout cas merci à tous les deux pour vos réponses.

Slaveak

[Elros]

Slaveak,

Si ton client à Visual studio 2010 en 32 bits, il doit pouvoir récupérer une version 64 bits non ? Dans une précédente mission j’ai débuté avec une version 32 bits (VS 2014) et on m'a donné sans difficulté la version 64 bits. Je ne pense pas qu'il ait un coût supplémentaire (à confirmer).


Pour le déploiement, je n'ai pas travaillé sur la version VS2010 donc il y'a des différences..
Lorsque tu parles de "Convertir le modèle de déploiement de projet", est-ce que tu es obligé d'ouvrir les packages ?
La conversion est obligatoire avant déploiement seulement, lorsque ton projet SSIS que tu as créé dans Visual Studio n'est pas de la même version que Integration Services.
Si ton projet Visual Studio à la même version qu'Integration Services ? tu peux logiquement t'en passer ! (A vérifier).

Elros

[Slaveak]

Elros,

Je vais voir avec mon client. Mais par contre une chose est sûre (ou quasi sûre) VS 2010 n'existe pas en 64 bits.
D'ailleurs je viens de me renseigner, C'est moi ou j'ai halluciné une version 64 bits ? Car d'après cet article, cela n'existe pas.

Et en même temps sur Technet je trouve ça.

Donc là je suis un peu paumé quand même.

Slaveak

[Elros]

Erratum, j'avais un ordinateur x64 (anciennement x86) avec une version VS en x86.

Pour ton lien Technet, on parle de SQL Server Integration Services et non de Visual Studio.

Sur un ordinateur 64 bits, si vous sélectionnez Integration Services pendant l'installation, le programme installe uniquement la version 64 bits du runtime et des outils. Si vous devez exécuter les packages en mode 32 bits, vous devez également sélectionner une option supplémentaire pour installer le runtime et les outils 32 bits

Si je comprend bien les versions x86 et x64 sont possibles.

Elros

[Slaveak]

Alors moi de ce que j'ai compris de toutes mes lectures c'est que :
- Visual Studio est 32 bits.
- SSIS est en gros un plugin de Visual Studio.
- Le plugin SSIS peut être lui, 64 bits.

Tout ceci est à confirmer bien sûr...

Enfin bref ! Je pense que mon problème inital s'est réglé par un accroissement de la place disque... car depuis que nous l'avons doublé je n'ai plus de soucis. C'est assez bizarre car je pensais vraiment que ça venait d'un manque d'accès RAM.