多くのDotNetNukeサイトで作業しますが、Microsoftのデータベース公開ウィザードを使用してスクリプトを作成するときに（私は共通の要素をまだ理解していません）私のDevサーバーで作成したサイトでは、ホスト（通常はGoDaddy.com）でスクリプトを実行し、サイトファイルをアップロードした後にエラーが発生します... 99.9％はファイル関連ではないことを確信しています、DBのどこから始めるべきかは不明です。残念なことにDotNetNukeではYSODを取得するのではなく、発生した実際の例外を見つける実際の方法がない一般的なエラーが発生します。MSFTからデータベース公開ウィザード経由で公開した後の問題
データベースパブリッシングウィザードを使用して誰かが同様の展開の問題を抱えていたのかどうか不思議です。私はRedGateツールセットを所有していますが、GoDaddyのようなホストでは、サーバーに直接接続することはできません。
データベース公開ウィザードの生成スクリプトは、通常はテーブル/制約を扱う際のプロシージャの作成私がやることは、まずデータベースをバックアップしてからスクリプトを実行することです。エラーが発生した場合は、そのクエリをスクリプトの最後に移動します。データベースの復元を続け、スクリプトが機能するまでスクリプトを実行します。
あなたは、web.configファイルに次のように設定することで、根本的なエラーメッセージを公開することができるはずです。
customErrors mode="Off"
あなたが手の込んだ「とサイトのファイルをアップロードする」だろうか？ DNNの新しいインスタンス？既存のサイトを更新しますか？ DNNのバージョンをアップグレードしますか？アップグレードまたは更新 - どのファイルを追加/上書きしていますか？
また、GoDaddyを使用している場合、WebサイトのID（ネットワークバージョンまたはIISバージョンに応じてasp.netマシンアカウント）にWebサイトのファイルシステムに対する十分な権限があることを確認できますか？変更権限が必要です。ファイルを上書きする場合は、これらを再適用する必要があります。
テストし、生成されたスクリプト（無料のSQL Express製品または完全な食事取引を使用して）。もしそれがローカルでうまく動くならば、あなたはそれが他の場所で実行されると確信することができます。
ローカルで実行するときに爆発する場合は、削除のプロセスを使用して、スクリプトの実行方法で問題のコードを探します。
私の勘違いは、スクリプトの順序がオフになる可能性があることです。私はだと思います。私はこれまでにデータベース公開ウィザードを使っていました。
あなたのフォローアップを読んでください。私はあなたの問題があったたびに、web.configの接続文字列と常に関係していました。それを見てからも、web.configでは常に接続文字列の問題でした。起き上がり、散歩して戻ってくる。
DNNのエラーページの1つを取得している場合、イベントログテーブルにエラーが記録される可能性があります。
私が見てしまう二つの領域があります -
を（あなたのsqldataprovider構成で 設定を見て）正確に何が起こっているとどのようなDNNがあなたを示している手動で、EventLogにテーブルの内側に見えるそこに格納されたXMLデータを引き出して、それを解析することができるかもしれませんスタックトレースと特定のエラーに関する詳細情報を検索します。
しかし、私は、すべてのオブジェクトが正しく動かされたことを100％確信しています。そして、正直言って私の経験ではうまく機能しています。
GoDaddyを使用して、私は別のMAJORのよくある問題は不正なファイルのアクセス許可で、DNNがweb.configやその他の必要なファイルを変更できないことを知っています。