1 秒リクエストでの表現 8.3. View フィールドとクエリ言語の View() 関数を操作する機能。 クエリコンソールの使用

レポートに参照フィールドを表示するには、リクエストで参照フィールドの表現を取得し、それを出力するときに、リンク自体ではなくそれを使用する必要があります。 このセクションでは、「View」フィールドのいくつかの機能と、ビューを取得するための関数 View() について説明します。 参照フィールドの出力の詳細については、「参照フィールドの出力」セクションを参照してください。

フィールド表現

インフォベース内の各オブジェクト テーブルには、仮想フィールド「ビュー」があります。 このフィールドには、オブジェクトのテキスト表現が含まれます。 クエリでは、他のテーブル フィールドと同じ方法でこのフィールドを取得できますが、このフィールドに対して操作を実行することはできません。 この機能は、このフィールドが仮想であるという事実によるもので、実際、データベースからこのフィールドを取得するときに、クエリは複数のフィールドを受け取り、クエリ結果からフィールド値を受け取るときに、受け取った値を変換します。文字列にします。 したがって、View フィールドでできることは、それをクエリ結果に取り込むことだけです。

そのため、クエリ結果を「表示」フィールドで並べ替えることはお勧めできません。 これでは望ましい結果は得られません。クエリ結果はオブジェクト参照の昇順に並べられます。 詳細については、「参照フィールドによる順序付けの機能」セクションを参照してください。

関数ビュー()

ビュー関数は、クエリ言語を使用して取得できる任意の値のテキスト表現を取得するように設計されています。 View() 関数は、参照型とプリミティブ型の両方で機能します。 参照型の場合、関数の結果は、関数にパラメーターとして渡された参照から「Representation」フィールドを受け取る場合と完全に似ています。 プリミティブ型の場合、関数の結果は、パラメーターとして渡された値が変換された文字列です。 この関数の特徴は、その結果を式で使用できないことです。 この機能は、クエリ結果からデータを受け取るときに、値の文字列への変換がすでに実行されているという事実によるものです。 値を文字列に変換するときはローカル設定を考慮する必要があるため、サーバー上でリクエストを実行するときに任意の値を文字列に変換することは行われません。

View() 関数を使用すると、View フィールドを使用する場合に比べていくつかの利点があります。 たとえば、表現の派生元のフィールドに参照型とプリミティブ型の両方が含まれる場合、そのようなフィールドからドットで区切られた表現フィールドを取得すると、プリミティブ型の値の表現が取得されなくなります。 ただし、そのようなフィールドに Representation() 関数が使用される場合は、フィールドに含まれる値のタイプに関係なく、文字列表現が取得されます。 さらに、View() 関数が 3 つ以上のテーブルへの参照であるフィールドに適用される場合、クエリ言語はデータベースから参照値のみを取得し、1 つ以上の追加クエリによってビュー値を取得します。 この動作により、実行中のクエリに、ビューを構成するフィールド。

Representation() 関数の使用は、COM 接続を通じてリクエストを実行する場合、フィールドの表現 (列挙) を取得するときにも役立ちます。

クエリ言語は、開発者にとって 1C 8.3 の基本的なメカニズムの 1 つです。 クエリを使用すると、データベースに保存されているデータをすばやく取得できます。 その構文は SQL に非常に似ていますが、いくつかの違いがあります。

SQL に対する 1C 8.3 (8.2) クエリ言語の主な利点は次のとおりです。

  • 参照フィールドの逆参照 (オブジェクトの詳細への 1 つ以上のポイントを参照)。
  • 結果の操作は非常に便利です。
  • 仮想テーブルを作成する機能。
  • リクエストは英語とロシア語の両方で書くことができます。
  • デッドロックを回避するためにデータをブロックする機能。

1C のクエリ言語の欠点:

  • SQL とは異なり、1C のクエリではデータの変更は許可されません。
  • ストアド プロシージャの欠如。
  • 文字列を数値に変換することは不可能です。

1C クエリ言語の基本構造に関するミニチュートリアルを見てみましょう。

1C のクエリではデータの受信のみが許可されるため、クエリはすべて「SELECT」という単語で始まる必要があります。 このコマンドの後に、データを取得する必要があるフィールドが示されます。 「*」を指定すると、使用可能なすべてのフィールドが選択されます。 データが選択される場所 (ドキュメント、レジスタ、ディレクトリなど) は、「FROM」という単語の後に示されます。

以下で説明する例では、命名法全体の名前が「Nomenclature」ディレクトリから選択されます。 「HOW」という単語の後には、テーブルとフィールドの別名 (名前) が示されます。

選ぶ
命名法 名前 AS 命名法名
から
Directory.命名法 AS の命名法

「SELECT」コマンドの横にキーワードを指定できます。

  • 様々な。 クエリは、少なくとも 1 つのフィールドが異なる行のみ (重複を含まない) を選択します。
  • 最初のN、 どこ n– 選択する必要がある結果の先頭からの行数。 ほとんどの場合、この構造は並べ替え (ORDER BY) と組み合わせて使用​​されます。 たとえば、日付が新しいドキュメントを一定数選択する必要がある場合です。
  • 許可された。 この設計により、現在のユーザーが使用できるレコードのみをデータベースから選択できます。 このキーワードの使用に基づいて、ユーザーはアクセス権のないレコードをクエリしようとするとエラー メッセージを受け取ります。

これらのキーワードは、一緒に使用することも、個別に使用することもできます。

変更のため

この提案は、相互の競合を防ぐためにデータをブロックします。 ロックされたデータは、トランザクションが終了するまで別の接続から読み取られません。 この句では、ロックする必要がある特定のテーブルを指定できます。 そうしないと全員がブロックされます。 この設計は自動ロック モードにのみ関係します。

ほとんどの場合、「FOR CHANGE」句は残高を受け取るときに使用されます。 結局のところ、複数のユーザーがプログラムで同時に作業している場合、あるユーザーが残高を受け取っている間に、別のユーザーが残高を変更することができます。 この場合、結果として得られる剰余は正しくなくなります。 この提案でデータをブロックすると、最初の従業員が正しい残高を受け取り、それに対して必要なすべての操作を実行するまで、2 番目の従業員は待機することになります。

選ぶ
相互和解、従業員、
相互決済 相互決済金額 残高
から
積立簿 従業員との相互決済 残高 AS 相互決済
変更のため

どこ

アップロードされたデータに何らかの選択を加えるにはデザインが必要です。 レジスタからデータを取得する場合には、仮想テーブルのパラメータに選択条件を指定する方が合理的です。 「WHERE」を使用すると、最初にすべてのレコードが取得され、その後でのみ選択が適用されるため、クエリの速度が大幅に低下します。

以下は、特定のポジションの連絡担当者を取得するリクエストの例です。 選択パラメータの形式は &ParameterName (パラメータ名は任意です) です。

セレクション(ケース)

この設計では、リクエストの本文で条件を直接指定できます。

以下の例では、ドキュメントが投稿されるかどうかに応じて、「AdditionalField」にテキストが含まれます。

選ぶ
入場料T&U.Link、
選択
入場時T&U.実施
その後、「書類は通過しました!」
ELSE 「文書は投稿されませんでした...」
追加フィールドとして終了
から
文書:商品およびサービスの受領方法 受領規約

参加する

結合は、特定の関係条件に基づいて 2 つのテーブルをリンクします。

左右の接続

LEFT 結合の本質は、最初に指定されたテーブル全体が取得され、接続条件に従って 2 番目のテーブルがそのテーブルにリンクされることです。 2 番目のテーブルに最初のテーブルに対応するレコードがない場合は、値として NULL が代入されます。 簡単に言うと、メイン テーブルは最初に指定されたテーブルであり、2 番目のテーブル (存在する場合) のデータはすでにそのデータに置き換えられています。

たとえば、品目は「商品およびサービスの受領」文書から取得し、価格は情報レジスタ「商品価格」から取得する必要があります。 この場合、ポジションの価格が見つからない場合は、代わりに NULL を代入します。 価格の有無に関係なく、ドキュメントのすべてのアイテムが選択されます。

選ぶ
領収書とU.命名法、
価格.価格
から
文書、商品およびサービスの受領、商品 HOW 受領 T&C
内部結合 RegisterInformation.PricesNomenclature.SliceLast AS 価格
ソフトウェアの受領書とU.命名法 = 価格.命名法

右ではすべてが正反対です。

完全接続

このタイプの接続は、結果として最初のテーブルと 2 番目のテーブルの両方のすべてのレコードが返されるという点で前の接続とは異なります。 指定されたリンク条件に基づいて最初または 2 番目のテーブルにレコードが見つからない場合は、代わりに NULL が返されます。

前の例で完全接続を使用する場合、「商品およびサービスの受領」文書のすべての品目アイテムと、「品目価格」レジスターのすべての最新価格が選択されます。 最初と 2 番目のテーブルの両方で見つからないレコードの値は NULL になります。

内部結合

INNER JOIN と FULL JOIN の違いは、少なくとも 1 つのテーブルでレコードが見つからない場合、クエリではそのレコードがまったく表示されないことです。 その結果、前の例で「FULL」を「INTERNAL」に置き換えると、情報レジスタ「品目価格」にレコードが存在する文書「商品およびサービスの受領」の品目項目のみが選択されます。

グループ化

1C クエリのグループ化では、特定の共通特性 (グループ化フィールド) に従ってテーブル行 (グループ化フィールド) を折りたたむことができます。 グループ化フィールドは、集計関数を使用してのみ表示できます。

次のクエリの結果は、製品タイプとその最大価格のリストになります。

選ぶ
,
MAX(価格.価格) AS 価格
から

グループ化
価格.命名法.命名法の種類

結果

グループ化とは異なり、合計を使用する場合は、すべてのレコードが表示され、合計行がレコードに追加されます。 グループ化では、一般化されたレコードのみが表示されます。

結果は、テーブル全体 (キーワード「GENERAL」を使用)、複数のフィールド、階層構造を持つフィールド (キーワード「HIERARCHY」、「ONLY HIERARCHY」) について要約できます。 結果を要約する場合、集計関数を使用する必要はありません。

グループ化を使用した上記の例と同様の例を見てみましょう。 この場合、クエリ結果はグループ化されたフィールドだけでなく、詳細なレコードも返します。

選ぶ
価格.命名法.命名法の種類 AS 命名法の種類、
価格.価格としての価格
から
情報の登録、名称の価格、最新の AS 価格のスナップショット
結果
最大(価格)
による
種類の名称

持っている

この演算子は WHERE 演算子に似ていますが、集計関数にのみ使用されます。 この演算子で使用されるフィールドを除く残りのフィールドはグループ化する必要があります。 WHERE 演算子は集計関数には適用できません。

以下の例では、アイテムの最大価格が 1000 を超える場合に、アイテム タイプごとにグループ化されて選択されます。

選ぶ

MAX(価格.価格) AS 価格
から
情報の登録、名称の価格、最新の AS 価格のスナップショット
グループ化
価格.命名法.命名法の種類
持っている
MAXIMUM(価格.価格) > 1000

並べ替え

ORDER BY 演算子は、クエリの結果を並べ替えます。 レコードが一貫した順序で表示されるようにするために、AUTO ORDER が使用されます。 プリミティブ型は通常の規則に従ってソートされます。 参照型は GUID によって並べ替えられます。

名前でソートされた従業員のリストを取得する例:

選ぶ
従業員.名前 AS 名
から
Directory.Employees HOW 従業員
並べ替え
名前
自動注文

その他の 1C クエリ言語構造

  • 組み合わせる– 2 つのクエリの結果を 1 つにまとめます。
  • すべてを組み合わせる– COMBINE に似ていますが、同一の行をグループ化することはありません。
  • 空のテーブル– 空のネストされたテーブルを指定するためにクエリを結合するときに使用されることがあります。
  • 場所– 複雑な 1C クエリを最適化するために一時テーブルを作成します。 このようなリクエストはバッチリクエストと呼ばれます。

クエリ言語の機能

  • 部分文字列指定された位置から指定された文字数まで文字列を切り詰めます。
  • 年...秒数値型の選択された値を取得できます。 入力パラメータは日付です。
  • 期間の開始と期間の終了日付を扱うときに使用されます。 期間のタイプ (DAY、MONTH、YEAR など) は追加パラメータとして示されます。
  • 追加日特定のタイプの指定された時刻を日付 (SECOND、MINUTE、DAY など) に加算または減算できます。
  • 差分日付 2 つの日付の差を決定し、出力値のタイプ (DAY、YEAR、MONTH など) を示します。
  • 無効である欠損値を指定された式で置き換えます。
  • 表現と表現リンク指定されたフィールドの文字列表現を取得します。 それぞれ任意の値に適用する場合と参考値のみに適用する場合があります。
  • タイプ、タイプ値入力パラメータのタイプを決定するために使用されます。
  • リンク属性値タイプの論理比較演算子です。
  • 急行値を目的の型に変換するために使用されます。
  • 日付時刻数値(年、月、日、時、分、秒)から「日付」型の値を取得します。
  • 意味 1C リクエストでは、ディレクトリ、列挙、特性の種類のプランなど、事前定義された値を示すために使用されます。 使用例:「 ここで、法的個人 = 値(列挙.法的個人.個人)«.

クエリビルダー

1C でクエリを作成するには、クエリ デザイナーという非常に便利な組み込みメカニズムがあります。 次の主要なタブが含まれています。

  • 「テーブルとフィールド」 - 選択する必要があるフィールドとそのソースが含まれています。
  • 「接続」 - CONNECTION 構造の条件を説明します。
  • 「グループ化」 - グループ化構造とそれらに基づく合計フィールドの説明が含まれます。
  • 「条件」 - リクエスト内のデータを選択します。
  • 「詳細」 - 「SELECT」コマンドのキーワードなどの追加のクエリパラメータ。
  • 「結合/エイリアス」 - テーブルを結合する可能性が示され、エイリアスが指定されます (「HOW」構造)。
  • 「順序」はクエリの結果を並べ替える役割を果たします。
  • 「合計」 - 「グループ化」タブに似ていますが、「合計」構成に使用されます。

リクエストのテキスト自体は、左下隅にある「リクエスト」ボタンをクリックすると表示されます。 このフォームでは、手動で修正するか、コピーすることができます。


リクエストコンソール

エンタープライズ モードでクエリの結果をすばやく表示したり、複雑なクエリをデバッグするには、 を使用します。 これにはリクエストのテキストが含まれ、パラメータを設定し、結果を表示します。

クエリ コンソールは、ITS ディスクまたは 経由でダウンロードできます。

1C 8 のクエリ言語は、よく知られている「構造化プログラミング言語」(SQL と呼ばれることが多い言語) を簡略化したものです。 ただし、1C ではデータの読み取りにのみ使用され、データの変更にはオブジェクト データ モデルが使用されます。

もう 1 つの興味深い違いは、ロシア語の構文です。 ただし、実際には英語の構文を使用することもできます。

リクエストの例:

選ぶ
銀行名、
銀行.CorrAccount
から
Directory.Banks HOW 銀行

このリクエストにより、データベースに存在するすべての銀行の名前とコルレス口座に関する情報を確認できるようになります。

クエリ言語は、情報を取得するための最も簡単かつ効果的な方法です。 上の例からわかるように、クエリ言語ではメタデータ名を使用する必要があります (これは、構成を構成するシステム オブジェクトのリストです。つまり、ディレクトリ、ドキュメント、レジスタなど)。

クエリ言語構造の説明

クエリ構造

データを取得するには、「SELECT」と「FROM」構造を使用するだけで十分です。 最も単純なリクエストは次のようになります。

SELECT * FROM ディレクトリ.命名法

ここで、「*」はテーブルのすべてのフィールドを選択することを意味し、Directories.Nomenclature – データベース内のテーブルの名前を意味します。

より複雑で一般的な例を見てみましょう。

選ぶ
<ИмяПоля1>どうやって<ПредставлениеПоля1>,
和(<ИмяПоля2>) どうやって<ПредставлениеПоля2>
から
<ИмяТаблицы1>どうやって<ПредставлениеТаблицы1>
<ТипСоединения>コンパウンド<ИмяТаблицы2>どうやって<ПредставлениеТаблицы2>
による<УсловиеСоединениеТаблиц>

どこ
<УсловиеОтбораДанных>

グループ化
<ИмяПоля1>

並べ替え
<ИмяПоля1>

結果
<ИмяПоля2>
による
<ИмяПоля1>

このクエリでは、テーブル「TableName1」と「TableName」からフィールド「FieldName1」と「FieldName1」のデータを選択し、「HOW」演算子を使用してフィールドに同義語を割り当て、特定の条件「TableConnectionCondition」を使用してそれらを接続します。 ”。

受信したデータの中から、「WHERE」の「データ選択条件」の条件を満たすデータのみを選択し、次にリクエストをフィールド「フィールド名1」でグループ化し、「フィールド名2」を合計し、フィールドの合計を作成します。 「フィールド名1」と最後のフィールド「フィールド名2」。

最後のステップは、ORDER BY 構造を使用してリクエストを並べ替えることです。

一般的なデザイン

1C 8.2 クエリ言語の一般的な構造を見てみましょう。

初めn

この演算子を使用すると、最初のレコードを n 個取得できます。 レコードの順序は、クエリ内の順序によって決まります。

最初の 100 を選択
銀行名、
銀行 コード AS BIC
から
Directory.Banks HOW 銀行
並べ替え
銀行名

リクエストは、「Banks」ディレクトリの最初の 100 エントリをアルファベット順に受信します。

許可された

この設計は、メカニズムの操作に関連しています。 このメカニズムの本質は、テーブル全体ではなく、データベース テーブル内の特定のレコードに対するユーザーの読み取り (およびその他のアクション) を制限することです。

ユーザーがクエリを使用してアクセスできないレコードを読み取ろうとすると、エラー メッセージが表示されます。 これを回避するには、「ALLOWED」構造を使用する必要があります。つまり、リクエストは、許可されているレコードのみを読み取ります。

選択許可
追加情報のリポジトリ。リンク
から
追加情報のディレクトリ.リポジトリ

様々な

「DIFFERENT」を使用すると、1C クエリ結果に重複行が入力されるのを防ぎます。 重複とは、すべてのリクエストフィールドが一致することを意味します。

最初の 100 を選択
銀行名、
銀行 コード AS BIC
から
Directory.Banks HOW 銀行

空のテーブル

この構造がクエリを結合するために使用されることはほとんどありません。 結合する場合、テーブルの 1 つに空のネストされたテーブルを指定する必要がある場合があります。 「EmptyTable」演算子はこれに最適です。

1C 8 ヘルプの例:

SELECT リンク.番号、空のテーブル (番号、品目、数量) AS 構成
FROM 文書.経費請求書
すべてを組み合わせる
SELECT リンク番号、内容 (行番号、製品、数量)
FROM 文書.請求書 文書.請求書.構成.*

無効である

多くの間違いを避けることができる非常に便利な機能です。 YesNULL() を使用すると、NULL 値を目的の値に置き換えることができます。 結合テーブル内の値の存在を確認する際によく使用されます。次に例を示します。

選ぶ
命名規則の参照リンク、
IsNULL(品目残り.数量残り,0) AS 数量残り
から


他の方法でも使用できます。 たとえば、各行の値がどのテーブルに存在するかが不明な場合は、次のようになります。

ISNULL(請求書受領日, 請求書発行日)

HOW は、テーブルまたはフィールドに名前 (同義語) を割り当てることができる演算子です。 上記で使用例を見ました。

これらの構造は非常に似ており、目的の値の文字列表現を取得できます。 唯一の違いは、REPRESENTATION は任意の値を文字列型に変換するのに対し、REPRESENTATIONREF は参照値のみを変換することです。 REPRESENTATION は、参照データ フィールドが選択で使用される予定がない限り、最適化のためにデータ合成システム クエリで使用することをお勧めします。

選ぶ
View(Link), //文字列、例:「2015年10月10日付け事前報告第123号」
View(DeletionMark) AS DeleteMarkText, //string, “Yes” または “No”
ViewReferences(DeletionMark) AS DeleteMarkBoolean //ブール値、True または False
から
書類・事前報告書

急行

Express を使用すると、フィールド値を目的のデータ型に変換できます。 値をプリミティブ型または参照型に変換できます。

参照型の Express は、複合型のフィールドで要求されたデータ型を制限するために使用され、システムのパフォーマンスを最適化するためによく使用されます。 例:

EXPRESS(TableCost.Subconto1 AS Directory.Cost Items).TaxAccountingCosts のアクティビティの種類

プリミティブ型の場合、この関数は長さが無制限のフィールド (そのようなフィールドは比較できません) の文字数を制限するためによく使用されます。 エラーを回避するには「 比較演算のパラメータが無効です。 フィールドを比較することはできません
無制限の長さと互換性のない型のフィールド
" の場合、そのようなフィールドを次のように表現する必要があります。

EXPRESS(行(150)としてコメント)

差分日付

1C の 267 ビデオ レッスンを無料で入手:

1C リクエストで IS NULL を使用する例:

から選ぶ
参照
LEFT CONNECTION RegisterAccumulations.ProductsInWarehouses.Remaining AS 製品の残り
ソフトウェア命名法Ref.Link = Sold GoodsCommitteesRemains.Nomenclature
残りの製品はありません。数量残りは NULL です

クエリ内のデータ型は、TYPE() 関数と VALUETYPE() 関数を使用するか、論理 REFERENCE 演算子を使用して決定できます。 2 つの機能は似ています。

事前定義された値

1C クエリ言語のクエリでは、渡されたパラメーターを使用することに加えて、事前定義された値または を使用できます。 たとえば、転送、事前定義されたディレクトリ、勘定科目表などには、「Value()」構造が使用されます。

使用例:

WHERE 命名法.命名法の種類 = 値(ディレクトリ.命名法の種類.製品)

WHERE 取引相手.連絡先情報の種類 = 値(列挙.連絡先情報の種類.電話)

WHERE 口座残高.会計口座 = 値(勘定科目表.利益.利益損失)

接続

接続には 4 つのタイプがあります。 , , 完全、内部.

左右の接続

結合は、特定の条件に基づいて 2 つのテーブルをリンクするために使用されます。 いつの機能 左結合つまり、最初に指定されたテーブル全体を取得し、2 番目のテーブルを条件付きでバインドします。 条件によってバインドできなかった 2 番目のテーブルのフィールドには値が入力されます。 ヌル.

例えば:

取引相手のテーブル全体が返され、「取引相手.名前 = 銀行.名前」という条件が満たされる場所のみ「銀行」フィールドが入力されます。 条件が満たされない場合、銀行フィールドは次のように設定されます。 ヌル.

1C 言語の RIGHT JOIN全く同じような 左接続 1 つの違いを除いて、 接続の権利「メイン」テーブルは最初ではなく 2 番目です。

完全接続

完全接続 left と right とは異なり、2 つのテーブルのすべてのレコードを表示し、条件によって接続できるレコードのみを接続します。

例えば:

から

完全接続
Directory.Banks HOW 銀行

による

クエリ言語は、レコードを結合する条件が満たされた場合にのみ、両方のテーブルを完全に返します。 左/右結合とは異なり、2 つのフィールドに NULL が出現する可能性があります。

内部結合

内部結合完全なレコードとは異なり、指定された条件に従って接続できるレコードのみが表示されます。

例えば:

から
ディレクトリ。カウンターパーティ AS クライアント

内部結合
Directory.Banks HOW 銀行

による
クライアント名 = 銀行名

このクエリは、銀行と取引相手が同じ名前を持つ行のみを返します。

協会

JOIN および JOIN ALL 構造は、2 つの結果を 1 つに結合します。 それらの。 2 つを実行した結果は、1 つの共通のものに「マージ」されます。

つまり、システムは一時テーブルに対してのみ、通常のシステムとまったく同じように動作します。

INDEX BYの使い方

ただし、考慮すべき点が 1 つあります。 一時テーブルへのインデックスの構築も完了までに時間がかかります。 したがって、一時テーブルに 1 ~ 2 を超えるレコードが存在することが確実にわかっている場合にのみ、「 」構造を使用することをお勧めします。 そうしないと、逆の効果が生じる可能性があります。インデックス付きフィールドのパフォーマンスは、インデックスの構築にかかる時間を補うことができません。

選ぶ
通貨レート 最新のクロスセクション 通貨 AS 通貨、
通貨レートの最新のクロスセクション。
PUT 通貨レート
から
情報レジスタ.通貨レート.最後のスライス(&ピリオド,) AS通貨レート最後のスライス
インデックスによる
通貨
;
選ぶ
価格命名法.命名法、
価格命名法.価格、
価格命名法.通貨、
通貨レート.レート
から
情報登録.命名価格.最終スライス(&ピリオド,
命名法 B (&Nomenclature) AND PriceType = &PriceType) AS PriceNomenclature
LEFT JOIN 通貨レート AS 通貨レート
ソフトウェア価格名称.通貨 = 通貨レート.通貨

グループ化

1C クエリ言語を使用すると、クエリ結果をグループ化するときに特別な集計関数を使用できます。 グループ化は、重複を「排除」するために集計関数を使用せずに使用することもできます。

次の関数が存在します。

金額、数量、異なる数、最大値、最小値、平均。

例 #1:

選ぶ
商品およびサービスの販売 商品、名称、
SUM(GoodsServicesGoods.数量の売上) AS 数量、
SUM(商品サービスの売上.金額) AS 金額
から

グループ化
商品およびサービスの販売 商品の名称

リクエストは商品を含むすべての明細を受け取り、それらを数量および品目ごとの金額ごとに要約します。

例その2

選ぶ
銀行コード、
QUANTITY(DIFFERENT Banks.Link) AS 重複の数
から
Directory.Banks HOW 銀行
グループ化
銀行コード

この例では、「Banks」ディレクトリ内の BIC のリストを表示し、それぞれに重複がいくつ存在するかを示します。

結果

結果は、階層構造を持つシステムからデータを取得する方法です。 集計関数は、グループ化と同様に集計フィールドにも使用できます。

実際に結果を使用する最も一般的な方法の 1 つは、商品の一括償却です。

選ぶ




から
ドキュメント. 商品およびサービスの販売. 商品 商品およびサービスの販売方法 商品
並べ替え

結果
SUM(数量)、
SUM(合計)
による
命名法

クエリの結果は次の階層になります。

一般的な結果

すべての「合計」の合計を取得する必要がある場合は、「GENERAL」演算子を使用します。

選ぶ
商品およびサービスの販売 商品の命名法 AS の命名法、
商品およびサービス商品の販売。AS ドキュメントへのリンク、
商品およびサービスの販売 商品の数量 AS 数量、
商品およびサービスの販売 商品の金額 AS 金額
から
ドキュメント. 商品およびサービスの販売. 商品 商品およびサービスの販売方法 商品
並べ替え
商品およびサービスの販売 商品. リンク. 日付
結果
SUM(数量)、
SUM(合計)
による
共通しています、
命名法

リクエストを実行した結果、次の結果が得られます。

グループ化の 1 レベルは、必要なすべてのフィールドの集約です。

アレンジする

ORDER BY 演算子は、クエリの結果を並べ替えるために使用されます。

プリミティブ型 (文字列、数値、ブール値) の並べ替えは、通常の規則に従います。 参照タイプのフィールドの場合、ソートはコードや参照表現ではなく、リンクの内部表現 (一意の識別子) によって行われます。

選ぶ

から
Directory.命名法 AS の命名法
並べ替え
名前

このリクエストにより、命名ディレクトリ内の名前のリストがアルファベット順に表示されます。

自動注文

並べ替えを行わないクエリの結果は、無秩序に表示される行のセットになります。 1C プラットフォーム開発者は、同一のクエリを実行したときに行が同じ順序で出力されることを保証しません。

テーブルのレコードを一定の順序で表示する必要がある場合は、Auto-Order 構造を使用する必要があります。

選ぶ
命名法.名前 AS 名
から
Directory.命名法 AS の命名法
自動注文

仮想テーブル

1C の仮想テーブルは、他の同様の構文にはない 1C クエリ言語の独自の機能です。 仮想テーブルは、レジスタからプロファイル情報を簡単に取得する方法です。

各レジスタ タイプには独自の仮想テーブルのセットがあり、レジスタ設定に応じて異なる場合があります。

  • 最初のカット。
  • 後者のカット。
  • 残り物;
  • 革命。
  • 残高と売上高。
  • サブコントからの動き。
  • 革命。
  • 速度 Dt Kt;
  • 残り物;
  • 残高と売上高
  • サブコン。
  • ベース;
  • グラフデータ。
  • 実際の有効期間。

ソリューション開発者にとって、データは 1 つの (仮想) テーブルから取得されますが、実際には 1C プラットフォームは多くのテーブルから取得し、それらを必要な形式に変換します。

選ぶ
倉庫内の製品の残存と回転。
倉庫内の製品残存および売上高.数量初期残存、
倉庫内の製品残存数と売上高、数量売上高、
倉庫内の商品残存数と売上高。入荷数量、
倉庫内の商品残存量と売上高.数量消費、
倉庫内の製品残数と売上高.数量最終残数
から
Accumulations.GoodsInWarehouses.RemainsAndTurnover を倉庫内の商品残存数と売上高として登録します

このクエリを使用すると、大量のデータを迅速に取得できます。

仮想テーブルのオプション

仮想テーブルを操作する上で非常に重要な点は、パラメータの使用です。 仮想テーブルパラメータは、選択と構成に特化したパラメータです。

このようなテーブルの場合、「WHERE」構造で選択を使用することは正しくないと考えられます。 クエリが最適ではなくなるだけでなく、間違ったデータを受け取る可能性もあります。

これらのパラメータの使用例:

蓄積の登録簿、倉庫内の商品、残高と売上高 (および期間の開始、および期間の終了、月、期間の移動および境界、命名法 = & 必須の命名法)

仮想テーブルのアルゴリズム

たとえば、最もよく使用される「Remains」タイプの仮想テーブルには、残高と移動という 2 つの物理テーブルのデータが保存されます。

仮想テーブルを使用する場合、システムは次の操作を実行します。

  1. 合計テーブルの日付と測定値に関して最も近い計算値が得られます。
  2. 移動テーブルの金額を合計テーブルの金額に「加算」します。


このような単純なアクションにより、システム全体のパフォーマンスが大幅に向上します。

クエリビルダーの使用

クエリビルダー– 1C Enterprise システムに組み込まれているツールで、データベース クエリの開発を大幅に容易にします。

クエリ ビルダーのインターフェイスは非常にシンプルで直感的です。 ただし、クエリ コンストラクターの使用方法をさらに詳しく見てみましょう。

クエリ テキスト コンストラクターは、プログラム コード内の目的の場所のコンテキスト メニュー (マウスの右ボタン) から起動します。

1C リクエスト コンストラクターの説明

デザイナーの各タブを詳しく見てみましょう。 例外は「ビルダー」タブであり、これについては別の説明で取り上げます。

「テーブルとフィールド」タブ

このタブでは、レポートに表示する必要があるデータ ソースとフィールドを指定します。 本質的に、ここでは SELECT.. FROM の構造について説明します。

ソースには、物理​​データベース テーブル、仮想レジスタ テーブル、一時テーブル、ネストされたクエリなどを使用できます。

仮想テーブルのコンテキスト メニューで、仮想テーブル パラメータを設定できます。

「接続」タブ

このタブは、複数のテーブルの接続を説明するために使用され、「CONNECTION」という単語を使用して構造を作成します。

「グループ化」タブ

このタブでは、テーブル結果の必須フィールドをグループ化して要約することができます。 GROUP BY、SUM、MINIMUM、AVERAGE、MAXIMUM、QUANTITY、NUMBER OF DIFFERENT という構造の使用について説明します。

「条件」タブ

WHERE 構築後のリクエスト テキストに含まれるすべてのもの、つまり、受信したデータに課せられるすべての条件に対して責任を負います。

詳細設定タブ

タブ さらに非常に重要なあらゆる種類のパラメーターが満載です。 それぞれのプロパティを見てみましょう。

グループ化 レコードの選択:

  • 最初のN– N 個のレコードのみをクエリに返すパラメータ (FIRST 演算子)
  • 重複はありません– 受信したレコードの一意性を保証します (DIFFERENT 演算子)
  • 許可された– システムが考慮して選択を許可するレコードのみを選択できます (許可された構造)

グループ化 リクエストの種類データの取得、一時テーブルの作成、または一時テーブルの破棄など、リクエストのタイプが決まります。

下には旗があります 受信したデータを後で変更できるようにロックする。 データ ロックを設定する機能を有効にすると、データが読み取られた瞬間から変更されるまでデータの安全性が確保されます (自動ロック モードにのみ関連し、変更用に設計されています)。

「結合/エイリアス」タブ

クエリ デザイナーのこのタブでは、さまざまなテーブルとエイリアスを結合する機能 (HOW 構造) を設定できます。 テーブルは左側に表示されます。 テーブルの反対側にフラグを設定すると、UNITE 構造が使用され、それ以外の場合は UNITE ALL (2 つの方法の違い) が使用されます。 右側には、異なるテーブルのフィールドの対応関係が示されており、対応関係が指定されていない場合、クエリは NULL を返します。

「注文」タブ

これは、値を並べ替える順序 (ORDER BY)、降順 (DESC) または昇順 (ASC) を指定します。

面白い旗もありますよ~ 自動注文(リクエスト内 - 自動注文)。 デフォルトでは、1C システムはデータを「混沌とした」順序で表示します。 このフラグを設定すると、システムは内部データによってデータを並べ替えます。

「クエリバッチ」タブ

[クエリ デザイナー] タブでは、新しいクエリを作成したり、ナビゲーションとして使用したりできます。 リクエストテキストでは、パケットは記号「;」(カンマ)で区切られます。

クエリデザイナーの「クエリ」ボタン

リクエスト デザイナーの左下隅には [リクエスト] ボタンがあり、いつでもリクエスト テキストを表示できます。

このウィンドウでは、リクエストを調整して実行できます。


クエリコンソールの使用

クエリ コンソールは、複雑なクエリをデバッグし、情報を迅速に取得するためのシンプルで便利な方法です。 この記事では、Query Console の使用方法を説明し、Query Console をダウンロードするためのリンクを提供します。

このツールを詳しく見てみましょう。

1C クエリ コンソールをダウンロードする

まず、クエリ コンソールの操作を開始するには、クエリ コンソールをどこかからダウンロードする必要があります。 治療法は通常、管理された治療法と従来の治療法 (8.1 および 8.2/8.3 と呼ばれることもあります) の 2 つのタイプに分けられます。

これら 2 つのビューを 1 つの処理で結合しようとしました。目的のフォームが目的の動作モードで開きます (マネージド モードでは、コンソールはシック モードでのみ動作します)。

1C クエリ コンソールの説明

メイン処理パネルの説明を含むクエリ コンソールを見てみましょう。

クエリ コンソール ヘッダーでは、最後のクエリの実行時間をミリ秒の精度で確認できます。これにより、パフォーマンスの観点からさまざまな設計を比較できます。

コマンド バーの最初のボタン グループは、現在のクエリを外部ファイルに保存する役割を果たします。 これは非常に便利で、いつでも複雑なリクエストの作成に戻ることができます。 または、たとえば、特定の設計の典型的な例のリストを保存します。

左側の「リクエスト」フィールドで、新しいリクエストを作成し、ツリー構造に保存できます。 ボタンの 2 番目のグループは、リクエストのリストの管理を担当します。 これを使用すると、リクエストを作成、コピー、削除、移動できます。

  • 実行するリクエスト– 簡単な実行と結果
  • パッケージを実行する– クエリのバッチ内のすべての中間クエリを表示できます。
  • 一時テーブルの表示– テーブルに対して一時クエリが返す結果を確認できます。

リクエストパラメータ:

リクエストの現在のパラメータを設定できます。

クエリ パラメーター ウィンドウでは、次のような興味深い内容が表示されます。

  • ボタン リクエストから取得開発者の利便性を考慮して、リクエスト内のすべてのパラメータを自動的に検索します。
  • フラグ すべてのリクエストに共通のパラメータ– インストールされている場合、その処理では、リクエストの一般リスト内のリクエストからリクエストに移動するときにパラメータがクリアされません。

値のリストを使用してパラメータを設定する非常に簡単です。パラメータ値を選択するときに、値のクリア ボタン (バツ印) をクリックするだけです。システムはデータ タイプを選択するように求めるプロンプトを表示します。そこで、「値リスト」を選択する必要があります。

上部パネルには、クエリ コンソール設定を呼び出すためのボタンもあります。

ここでは、自動保存クエリのパラメータとクエリ実行パラメータを指定できます。

リクエスト テキストはコンソールのリクエスト フィールドに入力されます。 これは、単にクエリ テストを入力するか、特別なツールであるクエリ デザイナーを呼び出すことによって実行できます。

1C 8 クエリ デザイナーは、入力フィールドをクリックするとコンテキスト メニュー (マウスの右ボタン) から呼び出されます。

このメニューには、リクエストのクリアや改行 (「|」) の追加、または次の便利な形式でのリクエスト コードの受信などの便利な機能もあります。

リクエスト = 新しいリクエスト。
リクエスト.テキスト = ”
|選択
| 通貨.リンク
|から
| ディレクトリ.通貨 AS 通貨」;
RequestResult = Request.Execute();

クエリ コンソールの下部フィールドにはクエリ結果フィールドが表示されます。これが、この処理が作成された理由です。



また、クエリ コンソールでは、リストに加えて、合計を含むクエリのデータをツリー形式で表示できます。

クエリの最適化

1C エンタープライズ 8.3 の生産性を向上させる上で最も重要なポイントの 1 つは、 最適化リクエスト。 この点も、次の場合には非常に重要です。 認定に合格する。 以下では、クエリのパフォーマンスが最適化されない一般的な理由と最適化方法について説明します。

WHERE 構造を使用した仮想テーブル内の選択

VT パラメーターを使用してのみ、仮想テーブルの詳細にフィルターを適用する必要があります。 いかなる状況でも、仮想テーブルでの選択に WHERE 構造を使用しないでください。これは、最適化の観点からすると重大な間違いです。 実際、WHERE を使用した選択の場合、システムはすべてのレコードを受け取り、必要なレコードのみを選択します。

:

選ぶ

から
蓄積の記録、組織の参加者との相互決済、残高 (
,
組織 = &組織
AND 個人 = &個人) HOW 組織の参加者との相互決済 残高

間違っている:

選ぶ
団体参加者との相互決済残高・金額残高
から
蓄積登録簿 団体参加者との相互決済 残高 (,) HOW 団体参加者との相互決済 残高
どこ
組織残高の参加者との相互決済 組織 = & 組織
かつ、組織残高の参加者との相互決済。個人 = &個人

ドットを使用して複合型のフィールドの値を取得する

ドットを介したクエリで複合型のデータを受け取ると、システムは複合型のフィールドで可能な型と同じ数のテーブルを左結合で接続します。

たとえば、最適化において登録レコード フィールド (レジストラ) にアクセスすることは非常に望ましくありません。 レジストラには複合データ タイプがあり、その中にはレジスタにデータを書き込むことができるすべての可能なドキュメント タイプが含まれます。

間違っている:

選ぶ
レコード設定.レコーダー.日付、
レコードセットの数量
から
SetRecordsとしてAccumulations.ProductsOrganizationsを登録する

つまり、実際には、このようなクエリは 1 つのテーブルではなく 22 のデータベース テーブルにアクセスします (このレジスタには 21 のレジストラ タイプがあります)。

右:

選ぶ
選択
WHEN ProductsOrg.Registrar LINK Document.製品およびサービスの販売
THEN EXPRESS(ProductsOrganization.Registrar AS Document.Sales of GoodsServices).Date
WHEN GoodsOrg.Registrar LINK Document.GoodsServices の受領書
THEN EXPRESS(GoodsOrg.Registrar AS Document.Receipt of GoodsServices).Date
日付として終了、
製品組織数量
から
RegisterAccumulations.ProductsOrganizations AS ProductsOrganization

または、2 番目のオプションは、そのような情報を詳細に追加することです (たとえば、この場合は日付を追加します)。

右:

選ぶ
製品組織.日付、
製品組織.数量
から
蓄積の登録簿、組織の物品 AS 組織の物品

結合条件内のサブクエリ

最適化のために、結合条件でサブクエリを使用することは受け入れられません。これにより、クエリの速度が大幅に低下します。 このような場合にはVTを使用することをお勧めします。 接続するには、接続フィールドによって事前にインデックスを付けたメタデータと VT オブジェクトのみを使用する必要があります。

間違っている:

選ぶ …

左結合 (
RegisterInformation.Limits から選択
どこ …
グループ化...
) による …

右:

選ぶ …
PUT制限
FROM 情報レジスタの制限
どこ …
グループ化...
インデックスによる...;

選ぶ …
FROM Document. 商品およびサービスの販売
LEFT JOIN の制限
による …;

仮想テーブルを使用したレコードの結合

仮想テーブルを他のテーブルに接続すると、システムが最適に動作しない場合があります。 この場合、クエリのパフォーマンスを最適化するために、一時テーブル クエリ内の結合フィールドのインデックス付けを忘れずに、仮想テーブルを一時テーブルに配置してみてください。 これは、VT が複数の物理 DBMS テーブルに含まれていることが多いため、その結果、VT を選択するためにサブクエリがコンパイルされ、問題は前の点と同様であることが判明します。

インデックスのないフィールドに基づく選択の使用

クエリを作成するときに最もよくある間違いの 1 つは、インデックスのないフィールドで条件を使用することです。これは矛盾しています。 クエリ最適化ルール。クエリにインデックス付け不可能なフィールドの選択が含まれている場合、DBMS はクエリを最適に実行できません。 一時テーブルを使用する場合は、接続フィールドのインデックスも作成する必要があります。

それぞれの条件に適したインデックスが必要です。 適切なインデックスは、次の要件を満たすものです。

  1. インデックスには、条件にリストされているすべてのフィールドが含まれます。
  2. これらのフィールドはインデックスの先頭にあります。
  3. これらの選択は連続的です。つまり、クエリ条件に含まれない値はそれらの間に「挟まれ」ません。

DBMS が正しいインデックスを選択しない場合、テーブル全体がスキャンされます。これはパフォーマンスに非常に悪影響を及ぼし、レコード セット全体のブロックが長引く可能性があります。

条件での論理和の使用

この記事では、すべての 1C 専門家が知っておくべきクエリ最適化の基本的な側面について説明しました。

クエリの開発と最適化に関する非常に役立つ無料のビデオ コース。 強くお勧めします初心者向けなど!

この記事では、1C v.8.2 クエリを使用するときに役立つテクニックと、クエリ言語についてあまり知られていない情報を提供します。 クエリ言語について完全に説明するつもりはありませんが、誰かにとって役立つかもしれないいくつかの点にのみ触れたいと思います。

それでは、始めましょう。 リクエストは 1C 8.2 の特別なオブジェクトです、システム内のデータベース テーブルに対するクエリを生成および実行するために使用されます。 クエリを実行するには、どのテーブルをクエリ データ ソースとして使用するか、どのフィールドを選択する必要があるか、どの並べ替えやグループ化を適用するかなどを説明するクエリ テキストを作成する必要があります。 クエリの詳細については、『1C 8.2 Developer's Guide』という書籍を参照してください。 1C 8.2 クエリ言語は、他の SQL データベース クエリ言語と構文がよく似ていますが、相違点もあります。 組み込みクエリ言語の主な利点の中でも、フィールドの逆参照、仮想テーブルの存在、合計の便利な操作、クエリ内の型なしフィールドなどは注目に値します。 欠点は、クエリを出力フィールドとして使用できないこと、ストアド プロシージャを使用できないこと、文字列を数値に変換できないことです。

クエリ言語に関する情報と推奨事項をポイントごとに提供します。
1. リクエストの可読性を高め、リクエストパラメータの数を減らすために、リテラルを使用してリクエスト内の事前定義された構成データにアクセスできます。 価値 (価値の表現)。値の表現としては、列挙値、ディレクトリの事前定義データ、計算タイプの計画、特性のタイプの計画、勘定科目表、空のリンク、ルート ポイントの値、システム転送の値 (たとえば、累積移動タイプ、口座タイプなど)を使用できます。
例:

WHERE City = VALUE(Directory.Cities.Moscow)
WHERE City = VALUE(Directory.Cities.EmptyLink)
WHEREProductType = VALUE(Enumeration.ProductTypes.Service)
WHEREMovementType = VALUE(MovementTypeAccumulation.Incoming)
ルートポイントはどこですか =
VALUE(ビジネスプロセス.Agreement.RoutePoint.Agreement)

括弧内の式は常に、事前定義された値のタイプに一致する単数形の単語 (ディレクトリ、列挙など) で始まります。

2.クエリ内の自動順序付けにより、プロセスが大幅に遅くなる可能性があります。 並べ替えが必要ない場合は、まったく使用しないほうがよいでしょう。 多くの場合、キーワードを使用して並べ替えを記述する方が効率的です。 並べ替え.

3.エイリアスを使用するときは、あいまいなフィールドが表示されないように注意する必要があります。 そうしないと、システムはどのオブジェクトにアクセスする必要があるかを認識できなくなります。
あいまいなフィールドを含むリクエストの例:
選ぶ
命名法.リンク、
残り商品Remaining.QuantityRemaining
から
Directory.命名法 AS の命名法
LEFT CONNECTION レジスタ蓄積 残品 残存 AS 残品 残存
ソフトウェア残りの製品Remaining.Nomenclature = Nomenclature.Link
たとえば、「Directory.Nomenclature AS Nomenclature1」のようにテーブルのエイリアスを修正する必要があり、「Nomenclature.Link」を「Nomenclature1.Link」に修正する必要があります。

4. キーワードを使用して参照フィールドの表現を取得すると便利な場合があります。 パフォーマンスデータベースに繰り返しアクセスしないようにするためのリンクも追加します。 これは、クエリの結果をテーブルに表示するときに便利です。
例:
選ぶ
REPRESENTATION(Document.Counterparty) AS 受信者、
プレゼンテーション(ドキュメント.ベース)
から
ドキュメント.請求書 AS ドキュメント

5.リクエストでの利用 EXPRESS(フィールドASタイプ)複合データ型のフィールドとの接続から不要なテーブルを削除できます。 これにより、リクエストの実行が高速化されます。
例 (レジストラは、残存商品の蓄積の登録簿の物理テーブルの複合タイプを持つフィールドであり、リクエストでは商品の受領文書の日付と番号が選択されますが、文書の詳細にアクセスする場合は、登録官、残存物品登録簿の登録官である文書のテーブルと登録簿テーブルの多重接続はありません):
いろいろ選択[b] EXPRESS(残存商品.レジストラ AS ドキュメント.商品の受領書).受領書番号としての番号、
[b] EXPRESS(残存商品.登録機関の文書.商品の受領書).受領日としての日付
[b]から 蓄積の登録簿。残存商品 AS 残存商品 どこ (EXPRESS(残存商品.登録機関の文書.商品の受領書) IS NOT NULL)

6. 1C 構成に、特定の構成オブジェクトに対する権限が制限されているユーザーがいる場合、そのようなオブジェクトへのリクエストでキーワードを使用する必要があります。 許可されたリクエストがエラーなしで実行されるようにする (「許可」を選択します...)

7. ネストされたテーブルを含むテーブル (たとえば、表形式の部分を含むドキュメント) をマージする場合、キーワードは便利です。 空のテーブルたとえば、ドキュメントの 1 つに表形式の部分がない場合です。
例:
SELECT リンク.番号、空のテーブル (番号、品目、数量) AS 構成

すべてを組み合わせる
SELECT リンク.番号、構成.(ライン番号、命名法、数量)
FROM 文書.請求書

8. それぞれ 1 行を含むテーブルの結合を操作する場合、テーブルの行を結合する必要がある場合があります (両方のテーブルには結合できるフィールドがありません)。 これは、「」という構造を使用することで実現できます。 TRUE による完全な接続テーブル」 テーブルに複数の行がある場合、結果は両方のテーブルの行数の積に等しい行数になります。 1 つのテーブルに O 行がある場合、結果のテーブルの行数は 2 番目のテーブルの行数と等しくなります。 また、このようなテーブルを接続するには、テーブルのデカルト積を使用できます。これにより、両方のテーブルの行のすべての組み合わせが結果のテーブルに表示されます。 いずれかのテーブルに 0 行がある場合、デカルト積は 0 になるため、完全結合の方が適切であることを覚えておく必要があります。 一般に、完全な接続ではなく、 真実によって他のタイプの結合を使用することもできますが、この場合、テーブルの 1 つにゼロ以外の行数がある場合でも、結果のテーブルの行が 0 になる可能性もあります。 完全結合の場合、両方のテーブルの行数が 0 の場合、この状況は 1 つのケースでのみ発生します。テーブルに少なくとも 1 行が正確に存在することがわかっている場合は、次のように使用できます。 左接続条件付きの別のテーブルを使用 真実によって.
例 (完全結合の場合、明らかに不自然です):
選ぶ
最初の 1
性別.リンク、
K. 取引相手
から
列挙。性別 AS 性別
フルコネクション (最初の 1 を選択 D. 文書から相手先を選択。商品の販売 HOW D 手配 D. 瞬間) HOW TO
オン(真)

9. 特定のフィールドの一意のレコードを取得するには、グループ化する代わりにキーワードを使用する方が正確です。 様々なこの構造はより明確であり、キーワードであるため、リクエストに含めます。 グループ化より幅広い用途があり、グループ化による集計関数の計算がさらに必要な場合によく使用されます。 場合によっては、限られた数の行を出力する必要があります。 これを行うには、リクエストの説明でキーワードを指定する必要があります。 初めそしてその後 - 必要な行数。
初め:
最初の 5 つを選択してください
ディレクトリ.命名法.名前、
ディレクトリ.命名法.購入価格
並べ替え
ディレクトリ.命名法.購入価格降順
様々な:
さまざまな選択
文書.消耗品.取引先

10.クエリ内の集計関数はキーワードなしで使用できます グループ。 この場合、すべての結果が 1 行にグループ化されます。
例:
選ぶ
金額(請求書.金額)を金額として
から
請求書としてのドキュメント.請求書.構成

11.選択フィールドのクエリでは、選択フィールドの詳細に自由にアクセスできます。 この機能は、選択フィールドの逆参照と呼ばれます。 データ ソースがネストされたテーブル (ドキュメントの表部分) の場合、選択フィールドでメイン テーブルのフィールドにアクセスすることもできます (たとえば、[リンク] フィールドを介して、メイン テーブルの Account のフィールドにアクセスします)。
例:
選ぶ[b] 商品およびサービスの受領 商品、数量 AS 数量、 商品およびサービスの受領Goods.Link.Counterparty から どこ
リクエストにグループ化がある場合にフィールドの逆参照を使用する場合には、1 つの特徴があります。 クエリ フィールドのリストにグループ化を含むクエリでは、グループ化フィールドの詳細に自由にアクセスできます。
例:
選ぶ
商品およびサービスの受領 商品の名称、
商品およびサービスの受領 商品、名称、コード、
SUM (商品およびサービスの商品の受領。数量) AS 数量、
商品およびサービスの受領Goods.Link.Counterparty、
商品およびサービスの受領Goods.Link.Date
から
文書. 商品およびサービスの受領. 商品 HOW 商品およびサービスの受領 商品
どこ
商品およびサービスの受け取りGoods.Link = &Link
グループ化
商品およびサービスの受領 商品の名称、
商品およびサービスの受け取りGoods.Link
1C ヘルプには、グループ化がある場合、グループ化フィールドと選択フィールドの集計関数のみがクエリ選択フィールドに参加できると記載されています。 集計関数が入れ子になったテーブルのフィールドに適用される場合、例外的なケースが 1 つあります。 この場合、選択フィールドのリストでは、結果をフィールドごとにグループ化せずに、最上位テーブルのフィールドにアクセスできます。
例:
選ぶ
商品およびサービスの受領、商品(合計(数量)、名称)、
商品およびサービスの受領リンク、
商品およびサービスの受領、取引相手
から
文書. 商品およびサービスの受領方法 商品およびサービスの受領方法
グループ化
商品およびサービスの受領、商品(名称)

12. 場合によっては、グループ化でフィールドを指定する代わりに、クエリ選択フィールドに次のパラメータを含めると便利です。
選ぶ DocProducts.命名法、 &カウンターパーティ、 &期間、 SUM(DocProducts.Quantity * DocProducts.Q) AS 数量、 SUM(DocProducts.Amount) AS 金額 から Document.Admission.Products AS DocProducts どこ DocProducts.Link = &Link
グループ化 DocProducts.命名法
次に、リクエスト本文にパラメータを設定します。
Request.SetParameter("&アカウント", SelectAccount);
Query.SetParameter("&Period", 日付);

13. ユニバーサル クエリでは、クエリ データ ソースの記述や条件でパラメータを使用できます。 どこ、テーブルの結合条件や仮想テーブルのパラメータなど。 汎用クエリを作成するには、次の 2 つの手法があります。
A) 文字列連結メカニズムを使用し、リクエスト テキストに変数を追加します。
例1:

OrderingType = ?(SOME VARIABLE,"","DESC");
Query.Text = "選択... BY フィールド 1 で配置 " + OrderType + "...";
例2:
Query.Text = "フィールド 1 を選択...";

ある変数 = 1 の場合
リクエスト.テキスト = リクエスト.テキスト + ",フィールド2 ...";
endIf;
B) リクエストのさまざまな部分 (リクエストのデータ ソース セクションなど) でパラメーターを使用し、次に組み込み言語メソッドを使用します。 STREPLACE()。ユニバーサル クエリを設計する場合、オブジェクトのプロパティにアクセスすると便利です メタデータ()これを使用して、リンクのテーブルの名前を決定できます (たとえば、ドキュメントの場合は次のようになります - Link . METADATA().NAME)、パラメータを介してユニバーサル プロシージャに渡されます。
例:
選ぶ
博士の命名法、
...
から
DocTC AS DocTC(&S)
次に、リクエスト本文にパラメータを設定します
Request.Text = StrReplace(Request.Text, "&SomeDocTCH", "Document."+Link.Metadata().Name+".Products");

パラメータをクエリ条件で使用して、オプションの条件を有効にすることができます &Parameter または NOT SomeProperty:
Request.SetParameter(“&Parameter”, “Counterparty.Name=””イワノフ”””);
リテラルの使用 真実リクエスト内の特定のフィルターを削除できます
Request.SetParameter("&パラメータ", True);

14.クエリ デザイナーで非常に便利なのは、テーブル コンテキスト メニュー コマンドです。 テーブルの名前を変更...これを使用して、データ ソースの一般化された名前を考えることができます。構造が類似した同じタイプのテーブルのクエリを作成するには、2 番目のテーブルが最初のテーブルのクエリ テキストをコピーすると便利です。クエリ デザイナー ウィンドウに移動し、テーブルのコンテキスト メニューで項目を選択します。 テーブルを交換...をクリックして 2 番目のテーブルを選択します。

15. クエリ デザイナーの仮想テーブルの条件またはパラメーターのセクションでネストされたクエリの作成を行う場合、括弧内のスペースを強調表示する手法が使用され、コンテキスト メニューに「クエリ デザイナー」項目が表示されます。ネストされたクエリを編集すると、条件内で括弧内のクエリ全体が強調表示されます。
ネストされたクエリの例:
製品 B (製品を選択...)

16. レジスターのバランスをとるためにクエリで ACS レポートを設計する場合、式を Period パラメーターとして使用する方が便利で正確です。 AddToDate(EndPeriod(期間,DAY),SECOND,1)、仮想残高は期間の初めに取得されるため、最後の 1 秒は含まれません。 +1 秒テクニックはドキュメントでは使用できません。ドキュメントを投稿する新しい方法によれば、登録残高は、Boundary オブジェクトで指定された期間、ドキュメントの時点を含む (日付ではなく) 受信する必要があります。ドキュメント +1 秒!)、古い投稿方法に従って、ドキュメントの時点で (ドキュメントの日付ではありません!)。 売上高や期間のデータを分析する場合、次のタイプのパラメーターを追加すると便利です。 標準期間(この場合、1 日の終わりに間隔の最後の日付を指定する必要はありません)。 標準フィールド「期間の開始」の場合、「式」フィールドに次の値を入力する必要があります。 "&Period.開始日」 また、「式」フィールドの標準フィールド「期末」に「」と記入します。 &Period.End Date」。クエリ言語に関する多くの有用な情報は、構文アシスタントではなく、1C 8.2 コンフィギュレーター (F1 ボタン) の完全なヘルプで見つけることができます。

17.クエリ機能 無効である(英語版を書いた方が便利です) 無効である) は通常、数値クエリ フィールドの Null 値を削除するために使用されます。 場合によっては、たとえば 2 つのテーブルの完全な結合、関数 IsNull (パラメータ 1,パラメータ 2)デザインを正常に置き換えることができます いつ...その後...それ以外...終了するかを選択してください、どのフィールドでも NULL 値が最初のテーブルと 2 番目のテーブルの両方に存在する場合があります (この構造により、フィールドの非 Null 値を取得できます)。 ただし、条件演算子とは異なり、次のことを覚えておく必要があります。 選択関数 無効である 2 番目の引数の型を最初の引数の型に変換します。引数の型が異なる場合は、これを考慮する必要があります。
例:
IsNull(登録残り,0)
IsNull(Doc.Product,Doc1.Item)

18. 条件付き工事時 選択特定の値と等しいかどうかをテストする単純なケースには別の構文がありますが、文書化されていません。
選択肢式 1の場合「高」 2の場合「中」 それ以外の場合「低」 終了

19. NULL値チェック演算子 はい ヌル(英語版の使用をお勧めします) 無効である)。 この構造は、少なくとも 1 つが Null である 2 つの値を比較する操作は常に false になるために出現しました。 書く ここで、名前 = Null間違っている。 この演算子の否定の形式も興味深いです ヌルなし- 間違っていますが、正しいです はい NULL ではありませんまたは形 いいえ (フィールド 1 がヌルです)- これは、He 演算子と組み合わせて使用​​されるすべての演算子との大きな違いです。

20. 演算子形式が役立つ場合がある リストされた値のいずれかと一致するかどうかを確認します。
例:
...製品名 B (「家電製品」、「コンピュータ」) はどこですか
参考書の場合は演算子形式が便利かもしれません 階層メンバーシップのチェック。
例:
...階層 (&グループ) の命名法はどこですか?
オペレーター サブクエリの結果に値が含まれているかどうかを確認するためによく使用されます。
例:
...Nomenclature.Link B (Nomenclature.Link を選択)。
サブクエリでは、条件内の外部クエリ フィールドにアクセスできます。
例:
// 存在した製品の名前を選択します
// 請求書内
選ぶ
製品名.名前
から
ディレクトリ.命名法 HOW 製品
どこ
製品.リンクB
(選ぶ
InvoiceComposition.Nomenclature
から
Document.Invoice.Composition AS InvoiceComposition
どこ
InvoiceContent.Nomenclature = Products.Link)
手術 配列、値のリスト、値のテーブル、ネストされたクエリで使用できます。 この場合、条件を下げることも可能です
サブクエリの構文
(式 1, 式 2,...,式 N) In (式 1, 式 2,...,式 N... を選択)
値テーブルの構文
(式 1, 式 2,...,式 N) (&TK) では、最初の N 列が TK 値のテーブルで使用されます。

20. インターネット上には、クエリ デザイナーのいつものやり方についてのジョークがあります。 指定方法に関係なく、テーブルを結合 (およびテーブルの交換) :
1C: 企業は「左向き」を好みます。

21. クエリ コンソールで複雑なクエリをデバッグすると便利です。 それらの多くはインターネット上にあります。 クエリをデバッグした後、クエリをコピーすると、クエリ デザイナーに素晴らしいボタンが表示されます。 リクエスト" を同じフォームに貼り付けて保存できます (以前は、コンフィギュレーターでコピーし、改行文字を使用してリクエストをフォーマットすることしかできませんでした)。 「クエリ」ボタンをクリックすると開くウィンドウで、クエリの編集や実行結果の確認ができ、とても便利です。

22.ACS レポートを設計するときは、特定のフィールドによるフィルタリングを提供する必要がある場合、リクエスト テキストにパラメータを追加する必要はないことに留意する必要があります。 クエリビルダーにはタブがあります。 データ構成"では、条件にパラメーターを追加できます。 さらに、ACS レポート レベルには、任意の条件を追加してクイック設定に保存できる条件タブがあります。 この場合、条件は普遍的になります(平等、不平等、帰属、リストへの包含など)。

23. ドキュメントを操作する場合、仮想テーブルフィールドによる並べ替えを追加する必要がある場合があります。 時の瞬間ただし、運が悪いことに、ネストされたクエリでは、このフィールドによる並べ替えが正しく機能しません。 タンバリンを持って踊ると効果的: 仮想フィールドによる並べ替え 時の瞬間は、日付順とリンク順の 2 つの並べ替えに置き換えられます。 ネストされたクエリを別のクエリに移動することで、一時テーブルを通じて問題を解決することもできます。 多くのリリースでは、この機能やバグは修正されていません。
指定された取引相手に最後に投稿されたドキュメント (ドキュメントの表形式の部分) を受信する、誤動作しているリクエストの例:

選ぶ
ConsumableProducts.リンク、
消耗品.行番号、
消耗品.製品、
消耗品、数量、
消耗品、価格、
ConsumableItems.Amount
から

どこ
消耗品 リンクB
(トップ 1 を選択
D.リンク
から
Document.Consumable AS D
どこ
D. リンク. 実施済み

ORDER BY D. リンク. 瞬間降順)

可能な解決策:
A) 次のように置き換えます 並べ替えの上
D.日付DESCで注文してください。
D.Link 降順で注文

B) ネストされたクエリを一時テーブルに移動できます。
トップ 1 を選択
D.リンク
TZLinkを入れる
から
Document.Consumable AS D
どこ
D. リンク. 実施済み
そして D.Counterparty = &Counterparty

並べ替え
D. リンク. 瞬間の降順
;

////////////////////////////////////////////////////////////////////////////////
選ぶ
ConsumableProducts.リンク、
消耗品.行番号、
消耗品.製品、
消耗品、数量、
消耗品、価格、
ConsumableItems.Amount
から
Document.Consumables.Goods AS ConsumablesGoods
どこ
消耗品 リンクB
(選ぶ
ティーリンク
から
TZLink AS T)
C) ドキュメントのメインテーブルを参照でき、その後でのみ表形式の部分を参照できます。
トップ 1 を選択
消耗品.リンク、
消耗品.グッズ(
リンク、
行番号、
製品、
量、
価格、

)
から
Document.Consumables AS 消耗品
どこ
Expense.Counterparty = &Counterparty
および消耗品。実施

並べ替え
消耗品。瞬間の減少

24. 文書の主テーブル(ディレクトリ)にアクセスすると、下位テーブル(表部分)のデータにもアクセスできます。 この機会はと呼ばれます テーブルフィールドの逆参照。 タスクの例としては、表形式のセクションで特定の製品を含むドキュメントを検索するタスクがあります。
例:
Receipt.Goods.Nomenclature = &Nomenclature の場合、Document.Receipt から Receipt.Link を選択します。

ネストしたテーブル Receipt.Goods に対するクエリと比較したこのクエリの利点は、ドキュメントに重複がある場合、クエリ結果はキーワードを使用せずに一意のドキュメントのみを返すことです。 様々な.
比較する:
Products.Nomenclature = &Nomenclature の製品として、「Document.Receipt.Products からのさまざまな Products.Link」を選択します。
おそらくこれですべてです。 クエリ言語には、私がカバーしていない疑問がまだたくさんあることは明らかです。 この記事を書くために、基本コース 1C 8.2 spec8.ru を完了した後に得た情報と、書籍「1C 8.2 Developer's Guide」およびインターネットから得た情報を使用しました。
ありがとうございます!

この記事では、あなたとすべてについて話し合いたいと思います 1C クエリ言語関数、 そして クエリ言語構造。 機能とデザインの違いは何ですか? 関数は括弧とその中に使用可能なパラメーターを使用して呼び出されますが、構造は括弧なしで記述されます。 間違いなく 1C クエリ言語のすべての構造と機能データ収集プロセスを柔軟かつ多機能にします。 これらの関数と構造はリクエスト フィールドに適用され、一部は条件にも適用されます。

1C クエリ言語関数

分かりやすい説明なので 1C クエリ言語関数構造の説明よりもはるかに一般的ではないため、関数について検討し始めることにしました。 次に、それぞれを個別に見て、その目的、構文、使用例を説明します。

1. 関数 日付時刻- この関数は、「日付」タイプの定数フィールドを作成します。

構文: 日付時刻(<Год>,<Месяц>,<День>,<Час>,<Минута>,<Секунда>)

使用例:

2. 日付差関数- 2 つの日付の差をいずれかの次元 (年、月、日、時、分、秒) で返します。 測定値はパラメータとして渡されます。

構文: 差分(<Дата1>, <Дата2>, <Тип>)

使用例:

Query.Text = "SELECT | DIFFERENCEDATE(DATETIME(2015, 4, 17), DATETIME(2015, 2, 1), DAY) | AS Qty.Days";

3. 関数値- データベースから事前定義されたレコードを使用して定数フィールドを設定します。また、任意のタイプの空のリンクを取得することもできます。

構文: VALUE(<Имя>)

使用例:

Request.Text = "SELECT //事前定義された要素 | VALUE(Directory.Currency.Dollar) AS Dollar, //空のリンク | VALUE(Document.Receipt of Goods and Services.EmptyLink) AS Receipt, //転送値 | VALUE(Transfer . 法人。個人) AS 個人、//事前定義された勘定科目 | VALUE(勘定科目表。自己サポート。材料) AS Account_10" ;

4. SELECT関数- コード内で使用される IF 構造の類似物が私たちの前にありますが、これのみが 1C クエリで使用されます。

構文: いつ選択するか<Выражение>それから<Выражение>さもないと<Выражение>終わり

使用例:

Request.Text = //金額が 7500 を超える場合、300 ルーブルの割引が必要です。 //したがって、条件がトリガーされた場合、関数は //Sum - 300 を返します //それ以外の場合、リクエストは単に Sum を返します"SELECT | SELECT | WHEN TCReceipts.Amount > 7500 | THEN TCReceipts.Amount - 300 | ELSE TCReceipts.Amount | END AS AmountWithDiscount |FROM | Document.Receipt of GoodsServices.Goods AS TCReceipts";

5. エクスプレス機能- 特定の型の定数フィールドを表現できます。

構文: EXPRESS(フィールド名 AS タイプ名)

使用例:

Query.Text = "SELECT VARIOUS | Sales.Registrar.Number, | SELECT | WHEN Sales.Registrar LINK Document.Consumable | THEN EXPRESS(Sales.Registrar AS Document.Consumable) | ELSE SELECT | WHEN Sales.Registrar LINK Document.Implementation | THEN EXPRESS(Sales.Registrar AS Document.Implementation) | END | ... | END AS Number | FROM | RegisterAccumulations.Purchases AS Purchases";

混合タイプのフィールドで EXPRESS 関数を使用するための別のオプションはありますか? 最も単純な例は、あらゆるレジスターの「レジストラー」です。 では、なぜレジストラで型を修飾する必要があるのでしょうか? レジストラから「番号」フィールドを選択するときの状況を考えてみましょう。番号はどのテーブルから選択されるでしょうか? 全員正解です! したがって、クエリを迅速に機能させるには、EXPRESS 関数を使用して明示的に型を指定する必要があります。

使用例:

Query.Text = "SELECT | EXPRESS(Nomenclature.Comment AS Line(300)) AS Comment, | EXPRESS(Nomenclature.Sum AS Number(15,2)) AS Sum |FROM | Directory.Nomenclature AS Nomenclature";

6. ISNULL関数(代替スペル ISNULL) - フィールドの型が NULL の場合、関数の 2 番目のパラメーターに置き換えられます。

構文: 無効である(<Поле>, <ПодставляемоеЗначение>)

使用例:

また、NULL 型を常に何らかの値に置き換えることをお勧めします。 NULL 型との比較は、NULL と NULL を比較した場合でも、常に FALSE を返します。 ほとんどの場合、NULL 値はテーブルの結合 (内部結合を除くすべての種類の結合) の結果として形成されます。

Query.Text = // アイテム全体とその残高を選択します // 一部のアイテムに残高がない場合は、フィールドが存在します // NULL は値 0 に置き換えられます "SELECT | No. Link, | ISNULL (ProductsInStockRemains.InStockRemaining, 0) AS Remainder | FROM | Directory.Nomenclature AS No. | LEFT CONNECTION 累積を登録します。 GoodsInWarehouses. Remainings AS GoodsInWarehousesRemains | ON (GoodsInWarehousesRemains. Nomenclature = No. Link)";

7. REPRESENTATION関数- リクエストフィールドの表現を取得できます。

構文: パフォーマンス(<НаименованиеПоля>)

使用例:

Query.Text = "SELECT | REPRESENTATION(FreeRemainingRemaining.Nomenclature) AS 名称、 | REPRESENTATION(FreeRemainingRemaining.Warehouse) AS 倉庫、 | FreeRemainingRemaining.InStockRemaining |FROM |Accumulation Register.FreeRemaining.Remaining AS FreeRemainingRemaining";

1C クエリ言語で構築します

上記であなたと話し合った 1C クエリ言語関数、今は検討する時期です 1C クエリ言語の構造体それらも同様に重要で便利です。始めましょう。

1. 建設リンク- は参照型をチェックするための論理演算子です。 複合型のフィールドを特定の型と照合するときに最も頻繁に発生します。 構文: リンク<Имя таблицы>

使用例:

Request.Text = //レコーダーの値のタイプが文書受領書の場合、 //クエリは「商品の受領書」を返し、それ以外の場合は「商品の販売」を返します。 "SELECT | SELECT | WHEN Remaining.Registrar LINK Document.Receipt of GoodsServices | THEN ""受入"" | ELSE ""消費"" | END AS 移動の種類 | FROM | 蓄積レジスタ。倉庫内の製品の残り AS 残り" ;

2. 間のデザイン- この演算子は、値が指定された範囲内にあるかどうかを確認します。

構文: 間<Выражение>そして<Выражение>

使用例:

Request.Text = //コードが 1 ~ 100 の範囲にある命名規則全体を取得します "SELECT | Nomenclature.Link |FROM | Directory.Nomenclature AS Nomenclature |WHERE | Nomenclature.Code BETWEEN 1 AND 100" ;

3. 建設BおよびB階層- 値が転送されたリストにあるかどうかを確認します (配列、値のテーブルなどはリストとして転送できます)。 IN HIERARCHY 演算子を使用すると、階層を表示できます (勘定科目表の使用例)。

構文: で(<СписокЗначений>)、階層内(<СписокЗначений>)

使用例:

Request.Text = // アカウントのすべてのサブアカウントを選択します "SELECT | セルフサポート。リンク AS アカウント | FROM | 勘定科目表。セルフサポート AS セルフサポート | WHERE | セルフサポート。リンク IN 階層値 (チャートアカウント。自立。商品)」;

4. 同様のデザイン- この関数を使用すると、文字列を文字列パターンと比較できます。

構文: のように "<ТекстШаблона>"

行パターンのオプション:

% - 任意の数の任意の文字を含むシーケンス。

任意の 1 文字。

[...] - 角括弧内にリストされた任意の 1 文字または一連の文字。 列挙では、範囲 (たとえば、a ~ z) を指定できます。これは、範囲の終わりを含む範囲に含まれる任意の文字を意味します。

[^...] - 角括弧内にリストされている単一の文字または一連の文字 (否定記号の後にリストされているものを除く)。

使用例:

Query.Text = //ルート TABUR を含み、 //小文字または大文字で始まる命名規則全体を検索します。 t "SELECT | 命名法。リンク | FROM | ディレクトリ。AS 命名法 | WHERE | 製品。名前 LIKE "" [Tt ]abur%""" ;

5. デザイン許可- この演算子を使用すると、呼び出し元が読み取り権限を持っているデータベースからレコードのみを選択できます。 これらの権利はレコード レベル (RLS) で設定されます。

構文: キーワード SELECT の後に ALLOWED が記述されます

使用例:

Request.Text = "SELECT ALLOWED | 取引相手。リンク | FROM | ディレクトリ。取引相手 AS 取引相手";

6. デザインいろいろ- 重複レコードがないレコードを選択できます。

構文: キーワード SELECT の後に VARIOUS を記述します

使用例:

Request.Text = // リーダーが権限を持つレコードを選択します "SELECT VARIOUS | Counterparties.Name |FROM | Directory. Counterparties AS Counterparties" ;

また、VARIOUS 構造は ALLOWED 演算子および他の演算子とともに使用できます。

使用例:

Request.Text = // リーダーが権限を持つさまざまなレコードを選択します "SELECT ALLOWED VARIOUS | Counterparties.Name |FROM | Directory. Counterparties AS Counterparties";

7. デザインファースト- パラメータで指定された数のレコードをクエリ結果から選択します。

構文: 最初<число>

使用例:

Request.Text = //ディレクトリから最初の 4 つの CCD 番号を選択します "SELECT FIRST 4 | CCD Numbers. Link | FROM | Directory. CCD Numbers AS CCD Numbers";

8. 変化のためのデザイン- テーブルをロックできます。トランザクション内でのみ機能します (自動ロックにのみ関連します)。

構文: 変更のため<НаименованиеТаблицы>

使用例:

Query.Text = "SELECT | 無料の残り 残り。命名法、 | 無料の残り 残り。倉庫、 | 無料の残り 残り。在庫あり 残り | FROM | 累計の登録。無料の残り。残り AS 無料の残り 残り | FOR CHANGE | 累計の登録. 無料の残り。残り」。

9. デザイン ORDER BY- 特定のフィールドごとにデータを整理します。 フィールドがリンクの場合、フラグを設定するときに 自動注文ソートはリンク表現によって行われます。フラグがオフの場合、リンクはメモリ内のリンク アドレスの優先順位によってソートされます。

構文: 並べ替え<НаименованиеПоля>自動注文

使用例:

Query.Text = "SELECT | 空き残数 残数。名称 AS 名称、| 空き残数 残数。倉庫 AS 倉庫、| 空き残数 残数。在庫あり 残り | FROM | 累計を登録します。空き残数。残り AS 空き残数 | | ORDER BY | 名称 | 自動注文回復";

10. デザイン GROUP BY- クエリ文字列を特定のフィールドごとにグループ化するために使用されます。 数値フィールドは集計関数で使用する必要があります。

構文: グループ化<НаименованиеПоля1>, .... , <НаименованиеПоляN>

使用例:

Query.Text = "SELECT | ProductsInWarehouses.Nomenclature AS Nomenclature, | ProductsInWarehouses.Warehouse, | SUM(GoodsInWarehouses.InStock) AS INSTOCK |FROM | RegisterAccumulations.ProductsInWarehouses AS ProductsInWarehouses | |GROUP BY | ProductsInWarehouses.Nomenclature, | ProductsIn Warehouses.Warehouse" ;

11. デザインハビング- WHERE 構造と同様に、集計関数をデータ選択条件に適用できます。

構文: 持っている<агрегатная функция с условием>

使用例:

Query.Text = // InStock フィールドが 3 より大きいグループ化されたレコードを選択します "SELECT | ItemsInStocks.Nomenclature AS Nomenclature, | ItemsInWarehouses.Warehouse, | SUM(ItemsInStocks.InStock) AS INSTOCK |FROM | RegisterAccumulations.ItemsInStocks AS ItemsInStocks | | GROUP BY | ProductsInWarehouses.Nomenclature、 | ProductsInWarehouses.Warehouse | |AVAILABLE | AMOUNT(ProductsInWarehouses.InStock) > 3" ;

12. 建設インデックスBY- クエリフィールドのインデックス付けに使用されます。 インデックス付きのクエリは完了までに時間がかかりますが、インデックス付きフィールドの検索は高速化されます。 仮想テーブルでのみ使用できます。

構文: インデックスによる<Поле1, ... , ПолеN>

使用例:

Query.Text = "SELECT | Ts.NameOS, | Ts.FolderNumber, | Ts.CodeOS, | Ts.Term, | Ts.Type | PLACE DataTs | FROM | &Ts AS Ts | | INDEX BY | Ts.NameOS, | Ts .CodeOS";

13. どこでデザインするか- 任意の選択フィールドに条件を課すことができます。 結果には、条件を満たすレコードのみが含まれます。

構文: どこ<Условие1 ОператорЛогСоединения УсловиеN>

使用例:

Query.Text = //CompensationRemaining を持つすべてのレコードが選択されます<>0 および //AmountForCalcCompRemaining > 100 "SELECT | CompensationRPORemains.Counterparty, |CompensationRPORemains.Child, | CompensationRPORemains.CompensationRemaining, | CompensationRPORemains.AmountForCalcCompRemains |Place DataTz |FROM | Accumulation Register.CompensationRP.Remains AS CompensationRPOstat ki |WHERE |Compensation RPORemaining.CompensationRemaining<>0 | そして CompensationRPORmains.AmountForCalcCompRemaining> 100" ;

14. 設計結果... 概要- 合計の計算に使用されます。設計では、合計の計算に使用されるフィールドと、合計フィールドに適用される集計関数を指定します。 TOTAL 構造に続いて各フィールドの合計を使用すると、データはグループ化されます。 オプションの GENERAL 構造があり、これを使用すると追加のグループ化も可能になります。 以下にリクエスト結果の例を示します。

構文: 結果<АгрегатнаяФункция1, ... , АгрегатнаяФункцияN>による<ОБЩИЕ> <Поле1, ... , ПолеN>

使用例:

Request.Text = "SELECT | 計算。カウンターパーティ契約。契約の種類 AS 契約タイプ、 | 計算。カウンターパーティ契約 AS 契約、 | 計算。カウンターパーティ、 | 計算。相互決済残高 AS 残高 | FROM | 蓄積の登録。相互取引相手との決済。残高 AS 計算 | 合計 | 金額 (残高) | ソフトウェア | 全般、 | 契約の種類」;

この図は、リクエストの実行中に形成されたグループの概要を示しています。一番上のグループは「GENERAL」セクションを参照し、2 番目のグループは「Counterparty ContractAgreement Type」フィールドを参照します。