Problèmes avec DB après publication via l'Assistant Publication de base de données MSFT

Question

Je travaille sur un certain nombre de sites DotNetNuke et parfois (je n'ai pas encore trouvé le facteur commun), lorsque j'utilise l'Assistant Publication de base de données de Microsoft pour créer des scripts pour le site que j'ai créé sur mon serveur Dev, après avoir exécuté les scripts sur l'hôte (habituellement GoDaddy.com), et téléchargé les fichiers du site, j'ai une erreur ... Je suis sûr à 99,9% que ce n'est pas lié au fichier , donc je ne sais pas par où commencer dans la DB. Malheureusement avec DotNetNuke vous n'obtenez pas le YSOD, mais une erreur générique, sans véritable moyen de trouver l'exception réelle qui s'est produite. Je suis simplement curieux de savoir si quelqu'un a eu des problèmes de déploiement similaires en utilisant l'assistant de publication de base de données, et si oui, comment ils les ont surmontés? Je possède le jeu d'outils RedGate, mais certains hôtes comme GoDaddy ne vous permettent pas de se connecter directement à leurs serveurs ...

Answer 1

Les scripts générés par l'Assistant de publication de base de données doivent généralement être modifiés, car la commande table est parfois erronée/création de procédure en traitant des contraintes. Ce que je fais est d'abord sauvegarder la base de données, puis exécuter le script, et si j'obtiens une erreur, je déplace cette requête à la fin du script. Continuez à restaurer la base de données et à exécuter le script jusqu'à ce qu'il fonctionne.

Answer 2

Vous devriez être en mesure d'exposer le message d'erreur sous-jacente en définissant ce qui suit dans le web.config:

customErrors mode="Off" 

Pourriez-vous préciser « et télécharger les fichiers du site »? Nouvelle instance de DNN? mettre à jour un site existant? mise à niveau de la version DNN? Si la mise à niveau ou la mise à jour - quels fichiers ajoutez-vous/écrasez-vous? En outre, lorsque vous utilisez GoDaddy, pouvez-vous vérifier que l'identité du site Web (service réseau ou compte d'ordinateur asp.net en fonction de votre version d'IIS) dispose des autorisations suffisantes sur le système de fichiers du site Web? Il devrait avoir des permissions de modification et celles-ci devront peut-être être réappliquées si vous écrasez des fichiers.

• IIS6 (XP, Server 2000, 2003) = ASP.Net compte de la machine
• IIS7 (Vista, Server 2008) = Service réseau

Answer 3

Testez vos scripts générés sur une nouvelle base de données locale (en utilisant le produit gratuit SQL Express ou l'offre complète de repas). Si cela fonctionne bien localement, alors vous pouvez être sûr qu'il fonctionnera ailleurs, toutes choses égales par ailleurs.

Si elle est bombardée lorsque vous l'exécutez localement, utilisez le processus d'élimination et parcourez l'exécution du script pour trouver le code incriminé.

Mon intuition est que l'ordre des scripts pourrait être désactivé. I pense Je l'avais déjà fait auparavant avec l'assistant de publication de base de données.

Answer 4

Lisez simplement votre suivi. Dans tous les cas où j'ai eu votre problème, c'était toujours quelque chose à voir avec la chaîne de connexion dans web.config. Même après des heures de visionnage, c'était toujours un problème de chaîne de connexion dans web.config. Lève-toi, fais une promenade et reviens.

Answer 5

Si vous obtenez l'une des pages d'erreur de DNN, il est possible qu'il ait enregistré l'erreur dans la table des événements.

Answer 6

Il y a deux domaines que je regardais -

1. Êtes-vous en cours d'exécution dans le schéma dbo et votre base de données a été scénarisé utilise dbo?
2. Utilisez-vous un qualificatif d'objet dans votre environnement de production ou dans votre environnement de production ? (Regardez vos paramètres de configuration de sqldataprovider )

Answer 7

Selon exactement ce qui se passe et ce que DNN vous montre que vous pourriez être en mesure de regarder manuellement dans la table EventLog, retirez les données XML qui y sont stockées, et l'analyser pour trouver la trace de pile et des informations détaillées concernant l'erreur spécifique à portée de main. J'ai cependant constaté que j'obtiens BEAUCOUP meilleur expérience globale avec les déploiements utilisant des sauvegardes et des restaurations de ma base de données, de cette façon je suis sûr à 100% que tous les objets se sont déplacés correctement, et honnêtement cela fonctionne mieux dans mon expérience. Avec GoDaddy, je connais un autre problème commun majeur: les autorisations de fichiers incorrectes, empêchant DNN de modifier le fichier web.config et les autres fichiers dont il a besoin.