1c8.3分散情報ベース。 RDBを最初から構築します。 RIBの基本原則

2016年10月25日

2ノードと10ノードのRIBの構成と保守に大きな違いはありませんが、リモートポイントの数が100を超える場合は、まったく異なる問題を解決する必要があります。

初期データ：

構成：小売2.2
プラットフォーム1C：8.3.7.1970

プロジェクト期間：年。

建築：

まず、RIBスキームを決定しました。可能な限りスタースキームに焦点を当てることが決定されました。技術的な限界に達したとき-スノーフレーク。

制限：
--2 GB RAM
-1つの物理プロセッサ

上記のすべての中で、負担となるのは主に最大データベースサイズの制限です。

しかし、これは、現場の古いデータからそれをクリーンアップするための手順を整理する必要があることを意味するだけです。

1CおよびMSSQLサーバーには個別の物理サーバーが割り当てられます。彼は交換と長期的な運営の主な負担を負います。
エンドクライアントコンピューターは、シンクライアントで動作し、負荷が最小限に抑えられるため、置き換えられません。
.

基本設定

もちろん、60ノットのRIBを導入する最初のプロジェクトを行ったUT 10.3の時代から、「橋の下にはたくさんの水が流れてきました」。

1Cは静止していませんでした。 Retail 2.2では、選択的なデータアップロードの必要性が考慮されるようになりました。
ストアに関連する情報のみがストアのデータベースにアップロードされます。
-すべての参考書（専門書を除く）
-このストアのドキュメント

もう1つの質問は、何らかの方法で、ベースにノードを追加することは、記録されるときに各共通要素の登録テーブルにもう1つのレコードを追加することを意味するということです。

1) アップロードとダウンロードのために別々の同期スクリプトに分割する必要があります
重要なのは、アップロードには時間がかかり、ロックが必要であり、ダウンロードは非常に手間がかからないということです。同時に、小売店からデータを迅速に受信する必要があり、1日に数回しかデータを返さないことがよくあります。

2）問題のあるストアを選択し、それらを一般的な同期シナリオから削除します。それらは大きなアンロードを持つ可能性があります-この場合、他のノードを含む交換全体が遅くなります。問題を解決した後、彼らは戻ってきます。

3）データを送受信するためのいくつかのシナリオを作成します。しかし、ここで重要なことは、それらの数の正しいバランスをとることです。
（バージョン8.1以降）。
その結果、RIBをアンロードする際の並列処理は制限されます。実際には、2〜3個のスクリプトを並行して実行することがわかります。

何を確定する必要があったか

1C RIBの標準ロジックで最も重要な障害は、更新です。

情報レジスターは交換のもう一つの問題です。各情報レジスタレコードをXMLにダンプすると、サービス要素などを含む個別のXMLノードが作成されます。さらに、100レコードが100行の結果テーブルを同時に受け取る情報レジスタの「SelectChanges（）」関数は、これが表形式のセクションに100行あるディレクトリの場合、1つのレコードのみが選択されます。そして、これは排他的ブロッキングの時間です。したがって、他の店舗で交換のために定期的に登録されているPC内のレコードが多数ある場合は、表形式のセクションを備えた参考書の形式で提示することは確かに正しいです。これは、極端な場合、記録時に形成される可能性があります。同じレジスタの行。ともかく、 .

もう1つの重要な詳細は何のために？割引カードはすでに300万近く蓄積されています。外部のオンラインシステムを使用して割引カードを操作します。割引カードをすべての店舗に転送し続けると、交換が大幅に増加し、さらに、基本ボリュームの10GBを超える可能性があります。

一部のメカニズムは、中央データベースに接続することでオンラインで実装されます。他の店舗の残高、別の店舗からの小切手による返品、商品券の有効性の確認などです。

複製

通常の方法で最初のRIBノードを作成すると、原則としてレプリケーションが不可能になります。
したがって、新しいノードは次のように作成されます:

2）このデータベースは、RIB内のすべての一般データを交換しますが、特殊な（ドキュメント）を受け取りません。

5）店舗の拠点ができました。

既製のソフトウェアパッケージがサーバーにデプロイされるため、それほど時間はかかりません。次に、新しく作成されたデータベースがサーバーにアップロードされ、ストアに送信する準備が整います。

シンクライアントのメリット

「魂を温めた」Retail2.2（シンクライアント）の2つの重要な利点：

サポートとアップデート

1）店舗の手で更新する（あまり正しくない、変更を受け取らない可能性がある、電話や問題が発生する）-以前と同じ

3）更新用の* .cmdまたは1Cスクリプトを作成するか、既製のスクリプトを取得します。実践が示すように、そのような解決策は常に中途半端な（不安定な）ものであり、それに少しの機能を組み込むことが可能になります。

私たちが持っていたタスク：

2）更新時に、ユーザーとのインタラクティブな対話が可能です（メッセージ、確認、プログレスバー）。

主な機能：

4）エージェントのステータスを確認する
5）レポートを更新する
6) バックアップ

たとえば、更新後のエラーメッセージは次のようになります。

したがって、プロジェクトは正常に完了する可能性が高くなります。沿って少なくともパスの真ん中で「通常の飛行」。

面白そうな他の解決策があれば、別に書きます

P.S. そして最も重要なこと：さらなるサポートの正しい計画は、そのようなプロジェクトのさらなる成功のための重要な要素の1つです。 :)

2016年10月25日

したがって、初期データ：

構成：小売2.2
プラットフォーム1C：8.3.7.1970
プロジェクト終了時の推定ノード数：200
センターの機器リソース：重要な制限はありません
その時点での機器：議論中の問題。
プロジェクト期間：年。

建築：

まず、RIBスキームを決定しました。以前は「スター」スキームに焦点を当てることが決定されました
V 小売店クライアントサーバーバージョンの作業が使用され、専用サーバーがWindowsOSで実行されます。
サーバー1Cは、バージョン「Server1CMINI」で使用されますhttps://1c.ru/news/info.jsp?id=17577
DBMSサーバー-MSSQL Express 2008R2。

SQL Express 2008 R2は、これまでのSQLServerのこのラインの最新バージョンです。
制限：

2 GB RAM
-1つの物理プロセッサ
-10GBの最大データベースサイズ

上記のすべての中で、データベースの最大ボリュームの制限は確かに厄介です。しかし実際には、これは、現場の古いデータからそれをクリーンアップするための手順を整理する必要があることを意味するだけです。

1CサーバーとMSSQLサーバーには別々のサーバーが割り当てられます。交換と運用の主な負担は彼にあります。
エンドクライアントコンピューターは、シンクライアントで動作し、下部の負荷が最小限になるため、置き換えられません。
ストア内のサーバーは単なる強力なPCです。ただし、前提条件は、MSSQLデータベースが配置されているSSDディスクの存在です。.
また、サーバーは、作業を中断することなく、夜間に日常的な操作を実行し、ストアデータベースにアクセスする機能を提供します。

基本設定

私が最初に60ノットのRIBを導入するプロジェクトを行ったUT10.3の時から、もちろん「橋の下にはたくさんの水が流れてきました」。 1Cは静止していませんでした。 Retail 2.2では、選択的なデータアップロードの必要性が考慮されるようになりました。
nemiuに関連する情報のみがストアのデータベースにアップロードされます。
-すべてのディレクトリ（一部を除く）
-このマグナジンに関する文書
データ登録は、キャッシュできるすべての登録ルールに従って行われます。登録時に大幅な遅延が正確に観察されるわけではありません。
もう1つの質問は、何らかの方法で、ベースにノードを追加することは、すべてのベースの共通要素ごとにもう1つのレコードを追加することを意味するということです。

アンロード自体の設定に特別なことは何もありません。同期シナリオを設定する際には、いくつかの微妙な違いがあります。

1) アップロードとダウンロードを別々の同期スクリプトに分ける必要があります。
重要なのは、アップロードには時間がかかり、ロックが必要であり、ダウンロードはまったく問題がないということです。同時に、小売店からデータを迅速に受信する必要があり、1日に数回しかデータを返さないことがよくあります。

2）問題のあるストアを選択し、それらを一般的な同期シナリオから削除します。それらは大きなアンロードを持つ可能性があります-この場合、他のノードを含む交換全体が遅くなります

3）データを送受信するためのいくつかの送受信スクリプトを作成します。しかし、ここで重要なのはバランスです。
1Cのいくつかのものは変わりません。同じ「SelectChanges」メソッドは順次実行することしかできません（バージョン8.1以降）。
その結果、RIBをアンロードする際の並列処理は制限されます。実際には、一度に2〜3のシナリオをアンロードすることが可能です。
受信のシナリオに関しては、もちろん、必要に応じて、ここではるかに多くの並列処理が可能です。

何を確定する必要があったか

もちろんそれは悲しいことですが、私はBSPに徹底的に取り組まなければなりませんでした。標準の1Cロジックで最も重要な障害は更新です..。更新後、次のようなウィンドウが表示されます。

これはすべて独占モードで発生します。特に、システムは、排他モードでの更新後も交換を試みます。これが何につながるかを推測するのは難しいことではありません。
この全期間中、店は働くことができず、顧客はチェックアウト時にいて、会社はお金を失います。

情報レジスターは交換のもう一つの問題です。 XMLで各情報レジスタレコードをアンロードすると、サービス要素とここから流れるすべてのものを含む個別のXMLノードが作成されます。さらに、100レコードの情報のレジスタに対して関数「変更を選択」すると、結果のテーブルには100行が含まれます。同時に、これが表形式のセクションに100行あるディレクトリの場合、1つのレコードのみが含まれます。選択されます。したがって、他の店舗で交換のために定期的に登録されているPCのレコードがたくさんある場合は、最後の手段として形成できる表形式のセクションを備えた参考書の形でそれを提示することは確かに正しいです記録時に同じレジスタの記録。ともかく、交換での情報レジスターは悪です.

もう1つの重要な詳細は割引カードは交換から完全に除外され、個人は特定の店舗の従業員のみになります。何のために？割引カードはすでに300万近く蓄積されています。外部のオンラインシステムを使用して割引カードを操作します。引き続きすべての店舗に割引カードを転送すると、交換が大幅に増加し、さらに、基本ボリュームの3GBを超える可能性があります。

一部のメカニズムは、中央データベースに接続することでオンラインで実装されます。他の店舗の残高、別の店舗からの小切手による返品、商品券の有効性の確認などです。

複製

もちろん、複製は加速されたペースで実行されています。
もちろん、最初のRIBノードを通常の方法で作成すると、レプリケーションが不可能になります。
したがって、新しいノードは次のように作成されます。

1）偽物の店がある別の拠点があります
2）このベースは、RIB内のすべての一般データを交換しますが、特殊なデータは受け取りません。
3）新しいベースを作成したい場合-これをコピーするだけです
4）次に、設定（保存、プレフィックスなど）を設定します。
5）店舗の拠点ができました。

既製のソフトウェアパッケージがサーバーにデプロイされるため、それほど時間はかかりません。次に、新しく作成されたストアデータベースがサーバーにアップロードされ、ストアに送信する準備が整います。

シンクライアントのメリット

「魂を温めた」2つの重要な利点。

1）小売店のコンピュータパーク全体を変更する必要はありません。操作の90％はサーバー上で実行され、サーバーは「比較的強力なコンピューター」になります。

2）機器には、動作を拒否する機能があります。特に、これは、新しく取り付けられた機器またはすでに摩耗した機器で発生することがよくあります。
この場合、アクションは非常に単純になりました。ストアは中央ベースで機能するように切り替わります。
このプロセスには5〜10分しかかからないため、機器に重大な問題が発生しても取引が中断されることはありません。

サポートとアップデート

最後に、最も興味深いポイントに到達しました-これをすべて維持および更新する方法は？
私たちにとって、更新も長い間問題になっています。

1）店舗の手で更新します（あまり正しくない、変更を受け取らない可能性があり、電話や問題が発生する可能性があります）
2）強制的に更新する技術サポート（それほど多くのリソースはありません）
3）* .cmdを記述して更新するか、既製にします。実践が示すように、そのようなソリューションは常に中途半端で（不安定）、機能はほとんどありません。

私たちが持っていたタスク：

1）更新はいくつかのモードで行われ、一元管理される必要があります
2）更新時に、ユーザーとのインタラクティブな対話が可能です。
3）ステータスと更新エラーに関するレポートを必ず受信してください
4）バックアップが必要です
5）更新システムは、問題なく自分自身を更新できる必要があります。
6）システムはあまり問題なく拡張可能でなければなりません。

もちろん、タスクは解決可能なリストをはるかに超えていました簡単な方法..。非常に多くのエンドポイントを使用した自動化が不可欠であり、同様の機能を備えた既製のものは多かれ少なかれ見つかりませんでした。
私はソフトウェアの開発を始めなければならず、それが最終的にMU（MagicUpdater）という名前になりました。

主な機能：

1）動的データベース更新（コマンドまたはスケジュール）
2）静的ベース更新（コマンドまたはスケジュール）
3）ターゲットコンピューターが変更されたときの自動エージェント
4）エージェントのステータスを確認する
5）レポートを更新する
6）バックアップ
7）サーバー1CおよびMSSQLを使用した管理アクション
8）ネットワークコンピューター上のすべての1Cクライアントアプリケーションを閉じる
9）メインチェックアウトで受け入れられる静的更新
10）更新後の変更内容の表示
11）アクションの順序を構成する
12）これらすべてのアクションをスケジュールに従って実行する

おおよその相互作用スキーム：

MU Agentは、ストアにインストールおよび構成されたサービスです。実際、彼女はセンターから特定のタスクを実行するようにコマンドを受け取ります。
MUサーバー-システムへのすべての要求を受け入れるサーバー。
MUモニター（通常のテクニカルサポートの従業員が見るもの）は、ログを表示したり、更新などのタスクを設定したりするために使用されます。

私の意見では、それはかなり良い結果になりました。現在、更新はほぼで行われています自動モード.
これは、たとえば、更新が中央に残った後、すべてが待機しているときにエラーメッセージが表示される方法です。

これが、クライアントコンピューターにコマンドを送信する方法です。

アプリケーションは確かに1Cではありませんが、かなりまともなインターフェイス機能のセットを備えています。たとえば、日付による選択は次のようになります。

これで、さらに複製する準備が整いました。さらなる支援の正しい計画は、そのようなプロジェクトのさらなる成功のための重要な要素の1つです。

1C 8.3アカウンティング（およびその他の構成）での分散データベース（RIB）の作成と構成は、1つのデータベースに同時に接続しながら、複数のユーザーが作業できない場合に必要です。標準のリモートデスクトップがうまく機能し、他のプログラムが提供するため、これは最近では非常にまれです。リモート接続データベースが配置されている中央コンピュータに接続します。

しかし、それにもかかわらず、単にインターネットがない状況があります。そして、データは1つのインフォベースにまとめられるはずです。このために、分散データベースが作成されます。

通常、メインベースはセントラルと呼ばれ、残りはペリフェラルと呼ばれます。つまり、手動モードまたは自動モード（設定に応じて）のいずれかで、データベースが1つに結合されます。新しく入力されたドキュメントとディレクトリコードの数が重複しないように、各データベースにプレフィックスが割り当てられます。

このマニュアルでは、例を使用して中央データベースと周辺データベースを作成し、それらの間の交換を確認します。このマニュアルは、1C8.3アカウンティングと1CTrade Management（UT）およびその他の構成の両方に適しています。

メイン（中央）分散RIBデータベースのセットアップ

1Cの[管理]メニューに移動し、[データ同期設定]リンクをたどってみましょう。開いたウィンドウで、「データ同期」チェックボックスを選択します。リンク「データ同期」がアクティブになります。ここですぐに、メインの情報ベースのプレフィックスを設定します。たとえば、「中央銀行」のようになります。

「データ同期」リンクに移動すると、「データ同期の構成」ボタンが表示されたウィンドウが開きます。このボタンをクリックすると、ドロップダウンリストが開き、「フル」モードを選択する必要があります。 1つの組織のみを同期する必要がある場合は、[組織別...]を選択する必要があります。

次のウィンドウで、プログラムはバックアップを作成するように提案します。次のセットアップ手順は元に戻せない可能性があるため、これを行うことを強くお勧めします。

作成後バックアップ「次へ」ボタンを押します。次のステップでは、同期がどのように行われるかを決定する必要があります。

ローカルディレクトリまたはローカルネットワーク上のディレクトリを介して。
FTP経由でインターネット経由。

例をわかりやすくするために、ローカルディレクトリを選択します。次のパスを指定しました：「D：\ Base 1C \ Synchronization」。このディレクトリへのエントリを確認する必要はありません。これには、特別なボタンがあります。

267の1Cビデオチュートリアルを無料で入手してください。

FTPと電子メールの同期を構成するための次の手順をスキップします。メインデータベースとペリフェラルデータベースの名前の設定にとどまります。ここでは、周辺ベースのプレフィックスを設定します。

各データベースのプレフィックスは一意である必要があることを忘れないでください。そうしないと、「最初のインフォベースのプレフィックスの値が一意ではありません」というエラーが表示されます。

「次へ」をクリックし、入力した情報を確認して、もう一度「次へ」をクリックし、「完了」をクリックします。「ファイルベースのフルネーム」フィールドで、同期用に作成されたディレクトリにあるファイル1Cv8.1CDを指定します。分散1Cデータベースの初期イメージを作成します。

1Cで初期RIBイメージを作成した後、同期スケジュールを設定するか、手動で同期することができます。

同期後、新しいデータベースに接続して、中央データベースからの情報がそこにアップロードされていることを確認できます。

新しいペリフェラルベースで、管理者権限を持つユーザーを少なくとも1人作成するだけです。

周辺データベースでの同期の設定

1Cペリフェラルベースでは、セットアップがはるかに簡単です。「データ同期」チェックボックスをオンにして、同じ名前のリンクをたどるだけで十分です。そして、私たちはほとんどすぐに「同期」ボタンのあるウィンドウに自分自身を見つけます。周辺機器データベースにテスト命名法を作成し、RIBを使用してメインデータベースにアップロードしてみましょう。

URBD（Distributed Database Management）コンポーネントは、狭い通信チャネル（モデム、電子メールなど）を介して2つ以上の同一の情報ベース（以下、IB）間で情報を交換する必要がある場合に使用されます。以下は、ステップバイステップの説明と実践的なアドバイス 1CでのURBDの設定について：Enterprise7.7。 2つのデータベースと同様に、より多くのデータベース用に構成することは難しくありませんが、2つの情報セキュリティの例を示します。

記事の著者：romix | 編集者：evGenius
22.02.08からの最終リビジョン№7| 話
URL：

キーワード：URBD、自動交換用スクリプト、ブランチ間の交換、メール、rom-mail.dll、DialMail.dll、CDO、ダイヤルアップ、URIB

URBD（Distributed Database Management）コンポーネントは、狭い通信チャネル（モデム、電子メールなど）を介して2つの同一の情報ベース（以下、IB）間で情報を交換する必要がある場合に使用されます。以下は、1C：Enterprise7.7でURBDを設定するためのステップバイステップの説明と実践的なアドバイスです。 2つのデータベースと同様に、より多くのデータベース用に構成することは難しくありませんが、2つの情報セキュリティの例を示します。

1）1C：EnterpriseプログラムのBINフォルダにあるDistrDB.dllライブラリは、URBDコンポーネントの操作を担当します。このコンポーネントは別途購入してインストールします。

2）自動交換の例では、2つのインフォベースを作成し、c：\ 1c_base1およびc：\ 1c_base2という名前のフォルダーに配置します。これらのフォルダーを作成し、それぞれにCPおよびPCという名前のサブフォルダー（ラテン文字）を作成します。

3）c：\ 1c_base1フォルダーに、既製の構成（たとえば、「Trade andWarehouse」）を配置します。ただし、最も単純な情報ベース（たとえば、複数のエントリを持つ1つの参考書のみを含む）でトレーニングすることをお勧めします。 URBD自動交換の結果として、データが1つの情報セキュリティから別の情報セキュリティに実際に移行することを確認することが重要です。これは、複雑なテストケースと最も単純なテストケースの両方で示すことができます。

4）Configuratorのすべてのウィンドウを閉じ、[管理]-[分散IS]-[管理]メニュー項目をアクティブにします。このメニュー項目は、1C：EnterpriseプログラムのBINフォルダーにDistrDB.dllコンポーネントが含まれている場合に使用できます。ライブラリのバージョンが間違っているか破損している場合は、現在のインストールに1C：Enterpriseを再インストールするだけです。DistrDB.dllライブラリは正しいバージョンに置き換えられます。

5）開いたウィンドウで、「CentralIB」ボタンをクリックします。リクエストウィンドウで、新しいインフォベースのコード（番号1を入力）とその説明（たとえば、 "Central IB"）を指定します。

6）[OK]をクリックして、変更の不可逆性に関する表示された警告を消します（以下に、文書化されていない方法、必要に応じてベースを元の状態に戻す方法について説明します）。

7）[新しい周辺機器]ボタンをクリックします。 IB "。リクエストウィンドウで、コード2と説明（「PeripheralIB」）を指定します。

8）シングルクリックで周辺ベースを選択し、「Config」を押します。自動交換」。開いたウィンドウで、スイッチを設定して、「手動」自動交換モードを「自動」に変更し、「OK」ボタンをクリックします。

9）[データのアップロード]ボタンをクリックします。アップロードしたファイルの名前を（クリップボードに）覚えておいてください "c：\ 1c_base1 \ CP \ 20.zip"-それでも私たちには役立ちます。 [OK]をクリックします。アップロードの最後に、1Cは「アップロードが正常に完了しました」と書き込みます。

10）Configuratorを閉じて、2番目のIBを配置するフォルダー（この例では-c：\ 1c_base2）を（Configuratorモードでも）入力します。データベースがDBF / CDX形式であることを示し、[OK]をクリックします。

11）[管理]-[分散IS]-[管理]メニュー項目に移動します。「情報ベースが見つかりませんでした。データをダウンロードしますか？」 [はい]をクリックしてアップロードファイルの名前（この例では "c：\ 1c_base1 \ CP \ 20.zip"）を指定し、[OK]をクリックします。ダウンロードの最後に、1Cは「ダウンロードが正常に完了しました」と書き込みます。セントラルISからデータをダウンロードすることにより、ペリフェラルISの作成に成功しました。

12）何かを変更します（たとえば、追加します新商品参考書）の情報ベースの1つ。私たちの目標は、ある（任意の）情報セキュリティの変更が、自動交換を通じて別の情報セキュリティに確実に反映されるようにすることです。メニュー項目「管理」-「分散情報セキュリティ」-「自動交換」を各拠点で交互に使用します。 CPおよびPCフォルダにZIP拡張子を持つ新しく表示されるアンロードファイルは、CP-> CP、PC-> PCの原則に従ってインフォベース間で移動（コピー）する必要があります（実際の「フィールド」条件では、これは通常、 Eメール).

ヒントとレシピ

1）分散データベースを通常のデータベースに変換するには、ファイル1SDBSET.DBF、1SDWNLDS.DBF、1SUPDTS.DBFとそれに対応する* .CDXファイル、および1SSYSTEM.DBFを削除します。基本的には、1SSYSTEM.DBFを削除するだけで十分です。その後、排他モードでプログラムを実行して、関連性のポイントを復元する必要があります。このトリックは文書化されていません（理由を推測します）が、それでも機能します。

2）1C構成を変更できますが、CentralIBでのみ変更できます。これは非常に便利です。周辺情報セキュリティの変更は自動的に「ロール」されます。

3）（たとえば、メールエラーの結果として）1つ以上のアップロードを失った場合、心配しないでください。 URBDはそのような状況を追跡し、次の自動交換セッションで失われたデータを再送信することができます。

4）1Cにメールを送信する標準機能は、電子メールクライアント（Outlookなど）との対話が発生したときに、MAPIインターフェイスを介して実装されます。私のアドバイス-時間を無駄にしないでください-MAPIとあらゆる種類のアウトラックを実際に使用すると、開発者がブランチ間を「すばやくドライブ」する必要がある問題が常に発生します。同じ理由で、直接ダイヤルアップ接続またはFTPを使用することはお勧めしません。 rom-mail.dllやDialMail.dllなどの外部コンポーネントを使用してメールを送信することをお勧めします。

別のオプションは、CDOを使用することです
http://avb1c.narod.ru/?=a9
（c）avb、不条理のマウスピース

5）自動交換を自動的に実行し、アップロードファイルを電子メールで送信できるプログラム。次の場所にアクセスできます。

いくつかの定数を正しく設定した場合（住所、パスワード、出席など）、ユーザーはショートカットをダブルクリックするだけで自動交換を開始できます。

プログラムは1C：エンタープライズ構成として実装されます。詳細な説明添付のDOCファイルに含まれています。

6）ISPに自動的にダイヤルする必要がある場合は、E-TypeDialerプログラムを使用します。彼女は、接続が成功したときに外部アプリケーションを起動する方法を知っています。もう1つのオプションは、モデムを操作する手段を備えた外部コンポーネントDialMailを使用することです（アドバイス-番号がパルスダイヤルを行う前にラテン語で「p」をプレフィックスし、番号の前に9W-「9」を介して呼び出して待機します）ダイヤルトーンなど）。

注：Windows XPには、rasdial.exeというダイヤラが組み込まれています。キーコマンドライン:
rasdial.exeアイテムユーザーパスワード
rasdial.exe要素/ DISCONNECT

7）中央ISで行われた変更が優先されます。インフォベースプレフィックスは、通常の1C構成（定数のこの設定を参照）で使用されるため、異なるデータベースで作成されたカタログアイテムのコードとドキュメント番号が一致せず、それらの一意性が侵害されないことに注意してください。

の簡単な説明

インストール数	無制限	アカウンティングコンポーネント7.7で使用	はい

周辺データベースの数	無制限	運用会計コンポーネントで使用する7.7	はい

スタンドアロンプログラム	番号	計算コンポーネント7.7で使用	はい

セキュリティキーの種類	USB	ロシア国内への配送は料金に含まれています	はい

配布キット	はい	購入機能	アプリケーションで

インストールマニュアルが含まれています	はい

なぜ1C：Enterprise7.7が必要なのですか。分散情報ベースの管理（1C URBD、1C URIB）

略語と略語：1C URBD-分散データベースの管理。 1C URIB-分散情報ベースの管理。

追加コンポーネント「分散情報ベースの管理」-1CURBD-1C URIB-は、整理に使用されます統一システムを持っている企業での自動会計 地理的に離れている部門（たとえば、本社、店舗、倉庫など） ローカルネットワークで接続されていません..。このコンポーネントによって提供される機能により、無制限の数の自律的に動作する周辺情報ベースを備えた分散情報システムの動作を編成することが可能になります。

分散情報ベース 1つの中央情報ベースと無制限の数の周辺情報ベースで構成されます。各インフォベースでは、新しいデータが入力され、既存のデータが個別に変更されます。システム構成は、中央情報ベースでのみ変更または更新することができます。セントラルインフォベースとペリフェラルインフォベースの間でデータを同期するには、変更されたデータを定期的に転送する必要があります。転送ファイルは、利用可能な方法（フロッピーディスク、電子メールなど）。システムはすべてのデータ変更を自動的に追跡し、説明されている同期ルールに従ってそれらを送信します。

1C URBDコンポーネントは、プロフェッショナルバージョンの1C：Enterprise7.7システムプログラムでのみ使用できます。

たとえば、本社と2つのリモート倉庫用に、「1C：Enterprise7.7。分散インフォベース管理」をいくつ購入する必要がありますか。

コンポーネント「1C：Enterprise7.7。分散情報ベースの管理」-1CURBD-は中央情報ベース。 1つのコンポーネントにより、無制限の数のペリフェラルインフォベースを同期できます。したがって、たとえば、本社と2つのリモート倉庫を同期するには、「1C：Enterprise7.7。分散インフォベース管理」のコピーが1つ必要です。

多くの場合、実際には、さまざまな部門または支店が地理的にさまざまな場所に配置されている場合があります。同時に、遠隔地のプログラムに入力されたデータは、一般会計が維持されるように、何らかの形で本社に到達する必要があります。

現在この問題多くの場合、地理的に離れた従業員に共通データベースへのリモートアクセスを提供することで解決されます。これは、データベースをWebサーバーに公開したり、リモートデスクトップを介して公開したりすることで実行できます。

ただし、地理的に離れたオフィスにインターネットがない場合や、一般的な情報ベースで機能するのに十分な安定性がない場合は、このような状況は珍しくありません。このため、1Cには分散データベースを構成するためのメカニズムがあります。

簡単に言えば、本社は本社にあります。リモート部門は部下を使用します。そのような従属基地がいくつかあるかもしれません。その結果、このような分散ベースは同期によって1つに結合されます。スケジュールに応じた自動モードと手動モードの両方で実行できます。

この記事では、1C：アカウンティング3.0用の分散データベースのセットアップを検討します。それにもかかわらず、この手順は他のほとんどの1C8.3構成に適しています。

ノート必要なすべての構成変更は、メインのRIBデータベースでのみ行う必要があります。同期中に、これらの変更はすべての下位ベースに転送され、有効になります。

主な情報ベース

分散データベースを使用する場合、メイン設定はメインデータベースに分類されます。下の画像に示すように、これらは「管理」セクションで作成する必要があります。

開いたウィンドウで、すぐに[データ同期]チェックボックスをオンにします。下部に、メイン（現在のベース）のプレフィックスを指定します。最大2文字の長さにすることができます。この場合、このRIB 1Cの「アカウント部門」を意味するため、プレフィックスは「BG」になります。

これで、同期自体の設定を開始できます。つまり、交換するベース（または複数のベース）データを指定できます。これを行うには、「データ同期設定」ハイパーリンクをたどります。左側のチェックボックスがオンになっている場合にのみ、移行に使用できます。

開いたウィンドウで、メニューから「Full ...」項目を選択します。これにより、同期用の1C情報ベースを指定できます。

地理的に離れたオフィスにある下位拠点を接続するための最初のウィンドウで、ローカルまたはネットワークディレクトリを介して接続が行われるフラグを選択します。この場合、これは「D：\ DB \ InfoBase」です。また、事前に書き込みの可能性を確認します。

ベースごとに異なるプレフィックスを指定してください。実際には、データを同期するときに、各データベースからオーバーロードされたデータに異なるプレフィックスが設定されます。それらが重複している場合、作業は正しくないため、プログラムはこの機会を提供しません。

プログラムが初期イメージの作成を求めるプロンプトを表示したら、このオプションを選択します。この手順には時間がかかります。その後、「1Cv8.1CD」という名前でコンピューターに保存します。

同期自体は、自分で構成できるスケジュールに従って自動的に実行することも、手動で実行することもできます。 2番目のケースでは、都合の良いときに[同期]ボタンをクリックするだけです。

RIBスレーブノード

下位ベースで行われる設定の数ははるかに少ないです。同じセクションで、「データ同期」フラグを設定し、対応するリンクをクリックすると、「同期」ボタンが使用可能になります。

この例では、「Beam」と「Board」の2つの命名項目がメインデータベースに追加されました。同期後、それらは下位ベースになりました。下の写真でわかるように、接頭辞「BG」が割り当てられています。他の2つの位置（「旋盤」と「パレット」）には、下位ベースに直接入力されたため、接頭辞「BP」が割り当てられました。

ノートこの場合の要素の番号付けは連続していますが、同じプレフィックス内でのみ行われます。