ユーザー、スキーマという概念が無い。あるわけですが、ライセンスの問題とか使える機能とか考えると、かなり有力な候補ですね。選択するメリットがあるかどうか・・・。利用できればですが)。1台のマシンでDBサーバーもWebサーバーもAPサーバーも・・・という条件だと、DBの子守りの手間が減って良いかも。シチュエーションで使うと威力を発揮してくれるのか思案のしどころです。しなくちゃいけないとなると、面倒だなぁ。トランザクション進行中に、ファイルをコピーしようとするとどうなるかとか・・・。(5)スポンサーリンクコメント各端末にSQLiteをいれて、サーバーデータの一時的な避難先。オフでも使えるシステムのために使おうかなと。以前から考えてたんだけど・・・AirではSQLite対応らしいのでアプリケーション作りやすくなりました。11:02コメントありがとうございます。使おうってことですね。切り替えればとりあえず運用は続けられるわけですよね。起動しておく必要がないから、普段の運用時はリソースを消費しないのもいいなぁ。データ量にもよるだろうけど、バックアップ兼スタンバイDBってわけですね。ナイスなご意見、ありがとうございました(こういう運用、ちょっと検討してみようかな)。トランザクション進行中はDBレベルでロックがかかる(ただしSELECTはできる)。ありますが、トランザクション中にSELECTを発行できますでしょうか?アプリAからテーブルXに1万件のデータをトランザクション開始して登録中に、アプリBからテーブルY(レコード1件のみ)にSELECTしてみましたが、結果が返って来るのはアプリAの動作が完了してからの様に見受けられました。SQLiteのバージョン情報は以下となります(.versionコマンドの結果)。09:45コメントありがとうございます。記事を書いた時は出来てたと思ってたんですけど・・・。一応検証もしたハズなんですけど・・・。16:44あばば無人君様ご指摘の件について検証してみました。検証手順は以下の通り初期状態:テーブルAに1行のデータが登録されている1.アプリA:トランザクション開始2.アプリA:テーブルAに1行追加(ジャーナルファイルの作成を確認)3.アプリA:テーブルAにselect発行。2行の応答を確認4.アプリBを起動5.アプリB:テーブルAにselect発行。1行の応答結果を確認6.アプリA:コミット(ジャーナルファイルがなくなる事を確認)7.アプリB:テーブルAにselect発行。上記結果から、トランザクション中もselectは可能と判断しています。いただいたコメントでは1万行追加の最中に検証されたようですので、可能性としてはディスクアクセスの関係でアプリBの応答が遅れたのかもしれませんが、よくわかりません。Out(URLは自動的にリンクされます。)メールアドレスは公開されません。名古屋在住のおっさん。日々の興味を徒然と綴っています。