やあ、
バックエンド データベースを MS アクセスから SQL サーバーに移行する作業を行っています。
私のアクセス アプリケーションは、マルチユーザーおよび多言語ベースです。
フロントエンドは、起動時にiniファイルを介して設定されたパラメータに基づいて、フォームとレポートの言語を適応させます。つまり、エンドユーザーの好みに適応させます。
アクセスでは、フロントエンド データベースの変換テーブルと、フォーム、レポート、ポップアップのすべての変換を処理する変換クラスを使用して解決しました。
ルックアップ テーブル (fi ドキュメント タイプ、連絡先タイプ、アカウント タイプなど) には、変換テーブル内の行への参照があり、クエリで必要に応じて、言語クラスへの呼び出しを処理するグローバル関数を使用して、要求されたデータを返します。適切な言語で。
したがって、ルックアップデータを含むいくつかのテーブル（ユーザーは編集できませんが、データの整合性のためにバックエンドに置きたい）には、プログラムフローを制御するためのいくつかのパラメーターに加えて、言語テーブルでそれらを取得するために使用する型の名前と説明の参照が含まれています。クエリ結果に表示されることがあります。
その最後の部分 (クエリ内の変換) を SQL サーバーのバックエンドで実装するのに行き詰まっています。
3つのオプションについて考えました：
1. SQL サーバーでビューを作成し、ビューをアクセス フロント エンドのテーブルとしてリンクし、次にアクセスで別のクエリをリンクし、変換機能を使用して余分な列を含むビューを選択します。
2. 上記と同じですが、パススルー クエリを表示してから、保存されたパススルー クエリ + 翻訳を選択する 2 番目のクエリを表示する代わりに。
3. ストアド プロシージャまたはテーブル値関数を作成して、要求されたパラメーターを言語として渡し、SQL サーバーで言語ルックアップを実装します。
ルックアップ テーブルの問題を解決しないため、言語ごとに個別のフロントエンドを使用することは解決策ではありません。
あなたのアドバイスは何ですか、別の解決策はありますか？
私が試したこと：
すでにテストデータで満たされたバックエンドデータベースを変換し、それにアクセスするためのコードを書いてテストしましたが、その特定の問題で立ち往生しました
コメント