レポートジェネレーターの異常な使用

彼のキャリアの夜明けに、彼は会計プログラムと会計システムの維持と執筆に対処しなければなりませんでした。 それ以来、18年が経過したという事実にもかかわらず、会計と報告に関連するすべてのものの拒絶は堅実に維持されてきました。 そして、運命がレポートジェネレーターを開発している会社に私を投​​げ込むと誰が思ったでしょう。 私の本質はすべてシステムプログラミングに引き寄せられ（そしてこれからも続きます）、レポートを生成するソフトウェアの開発に参加することは、若者の罪に対する罰です。 実際のところ、この記事では「ケージから抜け出す」試みと、互換性のないシステムプログラミングとレポートジェネレーターを組み合わせる試みについて説明します。



ドキュメントを書いたことはありますか？ そして、あなたが書いた場合、あなたはどのスタイルを使用しましたか-プロトコルのドライな説明またはライブの物語？ なぜかと言うと、ある時点でプロジェクトにドキュメントが必要だと気づいたからです。 ユーザーマニュアルとは異なり、プロトコルの説明は、all話や叙情的な逸脱のない退屈で単調な文書であり、送信および返されるパラメーターの説明を含むメッセージ形式のみです。 むかし、Microsoft Wordとスタイルシートを使用してこのようなことをしていましたが、実はプロトコルの単調な説明で正確なスタイルを維持することは非常に困難です。 信じないでください-自分で試してください。



ある時点で、アイデアが生まれました-プロトコルを記述するためにレポートジェネレーターを使用してみませんか？ 第一に、ドキュメンテーションを生成するために資金を購入する必要はありません。第二に、私の雇用者が自分で開発した製品のユーザーになる機会、第三に、さまざまな形式にエクスポートする能力、そして第4に、プレゼンテーションから情報を分離する本当の機会です。



すぐに言ってやった。 Microsoft Accessデータベースは、情報源として使用されました。 データベースの構造は次のように構成されています-基本情報は3つの関連テーブルにあります。



マスターテーブルのプロトコルには、基本プロトコルのリストと説明が含まれています。

詳細テーブルメソッドには、プロトコルメソッド（関数）のリストが含まれています。

サブディテールテーブルの引数には、各メソッドのパラメーター（引数）のリストが含まれています。



ドキュメントジェネレーターとして-FastReport.VCLレポートジェネレーター。 レポートデザイナーを起動し、[データ]タブを選択して、新しいADO接続を作成します。



レポートジェネレーターに組み込まれたアシスタントを使用して、次の行を取得しました。

プロバイダー= Microsoft.Jet.OLEDB.4.0;ユーザーID = Admin;データソース= ProtocolsSpecifications.mdb;モード=共有なしなし; Jet OLEDB：システムデータベース= ""; Jet OLEDB：レジストリパス= ""; Jet OLEDB：データベースパスワード= ""; Jet OLEDB：エンジンタイプ= 5; Jet OLEDB：データベースロックモード= 1; Jet OLEDB：グローバル部分一括処理= 2; Jet OLEDB：グローバルバルクトランザクション= 1; Jet OLEDB：新規データベースパスワード= "" ; Jet OLEDB：システムデータベースの作成= False; Jet OLEDB：暗号化データベース= False; Jet OLEDB：Compactでロケールをコピーしない= False; Jet OLEDB：レプリカ修復なしのCompact = False; Jet OLEDB：SFP = False;

次に、3つのデータソースをADO接続に追加し、3つのSQLクエリを使用してそれらをMaster-Detail-Subdetailバンドルにリンクしました。







クエリは次のようになります。

プロトコル：

SELECT P.Name, P.Description, P.ProtocolID, P.Description_Rus FROM Protocols P
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

方法：

 SELECT S.ProtocolID, S.Label, S.Name, S.Description, S.Description_Rus, S.ID FROM Methods S WHERE S.ProtocolID =:ProtocolID ORDER BY S.Label
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

引数：

 SELECT A.ID, A.InOutFlag, A.Index, A.TypedUntypedFlag, A1.Name, A.Name, A.Description FROM Arguments A INNER JOIN ArgType A1 ON (A.TypedUntypedFlag=A1.ID) WHERE A.ID =:ID ORDER BY A.ID , A.InOutFlag DESC, A.Index
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

その後、新しいページをレポートに追加して、レポートを作成できます。







IntelとAMDのハードウェア仕様を比較したことがありますか？ もしそうなら、誰のために？ 私の意見では、Intelのドキュメントは、ドキュメント内に多くの相互参照が存在し、アウトラインが優れているため、それを認識して操作するにはより便利です。 ドキュメントに概要を追加するには、情報を取得する方法と場所をレポートジェネレーターに伝える必要があります。 このため、バンドオブジェクト（実際には、データベースから選択されたデータが表示されます）にはOutlineTextプロパティがあり、静的テキストとデータベースの両方を入力できます。 バンドはネストできるため、アウトラインの情報は、ツリーの形式で取得され、ブランチはバンドのネストに対応します。





最良の部分は、生成されたドキュメントをPDFにエクスポートすると、アウトラインもエクスポートされることです。



FastReport.VCLレポートジェネレーターの一部として少しcr屈に感じていなければ、この記事は表示されませんでした。 事実、何らかの形で、レポートジェネレーターを使用してさまざまなインターネットリソースに関するドキュメントを作成することを既にやめましたが、突然、別の製品であるFastReport.NETを使用して同じ正確なレポートを作成したいという思いが思いつきました。 レポートコンバーターを使用して、外観が問題なくFR.​​VCL形式のレポートからFR.NET形式に変換されたことを確認しました。 これで喜びは終わりました-変換中のデータソースは失われました。 データベースへの接続を（「ウィザード」を使用して）再作成する必要があったため、次の行を取得しました。

プロバイダー= Microsoft.Jet.OLEDB.4.0;データソース= ProtocolsSpecifications.mdb;ユーザーID = Admin

そして、SQLクエリは次の形式を取りました。

 SELECT P.Name, P.Description, P.ProtocolID, P.Description_Rus FROM Protocols P
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ご覧のとおり、プロトコルのリクエストは変更されていません。 そして、他の2つのクエリでは、 WHERE句が消えました

 SELECT S.ProtocolID, S.Label, S.Name, S.Description, S.Description_Rus, S.ID FROM Methods S ORDER BY S.Label
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして

 SELECT A.ID, A.InOutFlag, A.Index, A.TypedUntypedFlag, A1.Name, A.Name, A.Description FROM Arguments A INNER JOIN ArgType A1 ON (A.TypedUntypedFlag=A1.ID) ORDER BY A.ID , A.InOutFlag DESC, A.Index
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

WHERE演算子の代わりに、[データ]ウィンドウで[アクション]メニューを選択し、[新しいリンク]メニュー項目を選択して、従属テーブルのリンクをメインテーブルに割り当てます。



編集が完了したら、Ctrlキーを押しながらラテンPを押すか、虫眼鏡アイコン上でマウスをクリックして、ドキュメントを生成し、結果のドキュメントをプレビューします。



FR.VCLとFR.NETを比較することはできません。 ドキュメントを生成する際、FR.VCLはレポート作成速度に関して最高の結果を示しました。 同時に、FR.NETは、わずかに多くのエクスポート形式（XPS形式など）、やや最新のインターフェイス、およびマネージコードによるフォールトトレランスの一定のマージンを提供します。



10回読むよりも1回試してみた方が良いと思う人のために、元のデータベースと2つのレポートテンプレートをzipアーカイブにFR3（FR.VCL）およびFRX（FR.NET）形式で投稿します 。 FastReportは公式サイトからダウンロードできます。 デザイナでレポートを開き、レポート内のデータベースパスを編集する必要があります。接続文字列では 、ProtocolsSpecifications.mdbファイルへのフルパスを指定する必要があります 。 ご不便をおかけして申し訳ございません。



最後に、プロトコル記述のこの方法の利点をもう一度見て、少し夢を見たいと思います。 主な利点は、情報とその表示の分離です。 開発者はプロトコルの説明に集中し、レポートジェネレーターがその外観を処理します。 広く使用されている多くのドキュメント形式にドキュメントを非常に簡単にエクスポートする機能。



MS Accessを任意のSQLサーバーに置き換え、データベースを編集するためのWEBインターフェイスをユーザーに提供する場合、複数の開発者が一度にリモートでプロトコルを開発できます。 幸いなことに、レポートジェネレーターには、レポートをその場で生成してHTTPプロトコルで送信できるサーバーバージョンがあります。



最後に、データベースはIDL（Interface Definition Language）の類似物として使用できます。 つまり データベースから直接インターフェースの記述を含むC / C ++ヘッダーファイルの生成を妨げるものはほとんどありません。



ご清聴ありがとうございました。