参入障壁が低くて、開発者の生産性が高くて、カスタマイズ性があって「独自のビジネスプロセスに非常に適合した」アプリができるのは本当にクールなんだけど、これらのシステムが基盤となるプラットフォームの能力を超えちゃうと、マジで辛いよね。今のクソみたいなオーバーレイネットワーク技術を使って「ネットワークドライブ」でDBFファイルにアクセスしようとする企業のことを考えるとゾッとする。アプリへのシームレスなリモートアクセスができないのが、Visual FoxProアプリの失敗するポイントだよね。見た目はいいけど、実際にそれで仕事したくはないな。クライアント/サーバー型のデータベースが透明に組み込まれたらいいのに。

最近これについて話さなきゃいけなかったんだ！俺のちょっと変わった名声の一つは、数年前にVisual FoxProのデータベースファイルをPostgreSQLに変換するツールを作ったことなんだ。しばらくの間、古いVFPアプリでデータ入力をするためにcronジョブとして動かしてたけど、他の人たちはPostgresバックエンドのウェブアプリで速いレポートを出せるようにしてた。見た目は良くなかったけど、すごくうまくいって、あの古いスタックから脱出する手助けになったよ。[0]https://github.com/kstrauser/pgdbf

2006年に医者のオフィスで働いてたんだけど、リードの医師がVisual FoxProを使って患者追跡のシステムを作ってたんだ。もう、ひどいもので、ネットワークドライブ越しに使うとファイルロックや同じレコードを複数人が変更する問題が起きてた（たいてい医師とフロントスタッフが患者をチェックアウトする時に）。なんとか医師を説得して、.NET WinFormsとASP.NET RPCコールを使ったちゃんとしたクライアント/サーバーアーキテクチャに切り替えさせたら、問題は全部解決したし、スタッフがアプリの上部に自分たちにとって重要な情報を表示できるようにインターフェースを編集できるようにしたんだ。ラボテストのフォームをXMLで作ったから、X/Y座標を好きな場所に移動できるようにしたんだ。これは俺が考えた機能じゃなくて、医師が技術を見てどう動くかを理解した結果なんだ（幸運なことにビジネスとセキュリティのロジックはサーバーにあったから、悪意のある人ができるのは自分のローカルコピーを壊すことだけだった）。

FoxProをどんな形でも復活させるのが難しい理由は、データベースコンテナ（DBC）の設計に大きなセキュリティホールがあるからなんだ。DBCが役立つためには、すべてのユーザーが読み書きできる必要がある（権限の仕組みがない）。DBCには、FoxProのコードを実行できるストアドプロシージャがあって、FoxProランタイムからのWin32コールも含まれてる。ストアドプロシージャは「メモ」フィールドにプレーンテキストとして保存されてる。これがどうなるか分かる？ちょっとした技術知識があれば、そのINSERTトリガーを好きなように変更できるんだ。EDIT: データベースはファイルシステム内のファイルに過ぎないから、テキストエディタを使って修正できて、FoxProランタイムのチェックをバイパスできる。FoxProはそこにあるものをそのまま実行するだけ。俺のおすすめは、DBF/DBCファイルを早急に廃止して、何らかのSQLデータベースに移行することだ。ソースコードがあるなら、ODBCやOLE DBを使ってサーバーを指すべきだよ。ソース: 20年以上前にFoxチームで働いてた時にそのバグを報告した。いや、DBエンジンの動作の大部分を再構築しない限り、修正されることはなかった。