何ら関係ないのに、何故そのようなエラーがそんな場所で出るのかまったく分かず、半日ぐらいハマってしまいました。別プロジェクトにすることです。経由でデータベースに接続に行くということです。いうようにすると、そこでデーターベースに接続に行きます。接続に用いる接続文字列が必要です。これの解決にも半日ぐらいハマってしまいました。プロバイダーと併用することを意図していないか、または無効です。いうエラーになります。自動的に名前が付けられたデータベースをアタッチできませんでした。共有に配置されています。いうエラーになります。用いる場合、サーバーでのデータベースの作り方を備忘録として書いておきます。フォルダに自動生成してくれます。ファイルをサーバーにコピーして使うことができます。使って実行する手もあります)しかしながら、ホスティングサービス(レンタルサーバー)を利用している場合は上記のようなことはできません。にアタッチしてもらうのも望み薄です。管理ツールを提供しているはずなので、そのツールからスクリプトを走らせることができれば、遠隔地にあるサーバーにデータベースを作成することができるはずです。以下に、自分が使っているホスティングサービス(ActiveWeb)の場合の例を書きます。場合も、同じ会社がサービスしているので、手順は大筋で同じです。(他のホスティングサービスの場合は不明です。データベースを作成し、ユーザーの設定をします。設定するので覚えておいてください。スクリプトファイルを生成します。以下のようにコマンドラインから入力します。スクリプトファイルの名前です。作ったスクリプトを走らせ、データベースにテーブル、ストアドプロシージャ、トリガを作成します。下の画像を参照してください。作ったスクリプトを指定します。接続文字列を実環境に合わせて修正します。認証で接続するのが普通だと思います。その場合、接続文字列は以下のようになるはずです。不明な点はレンタルサーバー会社に確認してください。アプリから接続できるようになっているはずです。データベースのテーブルの中身は空なので、自分でユーザー登録とロールの設定が必要です。管理用のページを作るなりしないとユーザー登録やロールの設定はできないので、そこが少々面倒かも知れません。手順は不要になるはずです。書きましたが、続けて「永続化」した時としない時の動作の違いを備忘録として書いておきます。よって有効期限が指定されます。分)だけ先の日時になります。認証クッキーは認証チケットの入れ物に過ぎないことに注意してください。認証チケットの有効期限は、ユーザー名などの他の情報と一緒に暗号化されて、認証チケットの中に含まれています。[永続化」した場合の認証クッキーの有効期限は、認証チケットの有効期限と同じになりますが、認証クッキーの有効期限で認証チケットの有効期限を判定しているわけではありません(そもそも、サーバー側ではクライアントから送られてきたクッキーの有効期限はわかりません)。認証チケットが発行された以降、有効な認証チケットがブラウザからの要求と一緒にサーバーに送られてくれば、サーバーはユーザーを認証済みと見なし、匿名アクセスが許可されてないページへのアクセスを許可します。認証チケットが送られてこない場合、もしくは送られてきた認証チケットが期限切れの場合、サーバーはユーザーをログイン画面へリダイレクトします。属性で設定した時間の半分を過ぎてアクセスすると、有効期限が延長された認証チケット/クッキーが再発行されます。上の既存の認証クッキーが上書きされます。認証クッキーを「永続化」した場合としない場合(即ち、認証クッキーの有効期限の有無)では、以下のように動きが異なります。取得してサーバーに送ります。クッキーの有効期限が切れると、ユーザーが次にサイトを訪問した時にブラウザによって削除されます。分程度の短い時間に設定した場合はほとんど意味がないです。日)に設定してありました。「永続化」もこのぐらい長ければ役に立つと思いますが。設定しておく方がよさそうです。「永続化」しない場合この場合、認証クッキーはブラウザのメモリにしか保持されません。従って、ブラウザを閉じれば認証クッキーは消えます。逆に、ブラウザを閉じなければ認証クッキーは消えません。要求のたびに送られ続けます。blog2010年5月にこのブログを立ち上げました。関係のトピックス、ブログ2はそれ以外のトピックスに分けました。