sanryuブログ

    ''' 

    ''' プリンタジョブを取得する
    ''' 
    ''' プリンタ名
    ''' 
    ''' 
    Public Shared Function GetPrintJobsCollection(ByVal printerName As String) As List(Of String)
　
        Dim printJobCollection As New List(Of String)
        Dim searchQuery As String = "SELECT * FROM Win32_PrintJob"
        Dim searchPrintJobs As ManagementObjectSearcher = New ManagementObjectSearcher(searchQuery)
　
        Dim prntJobCollection As ManagementObjectCollection = searchPrintJobs.Get()
　
        For Each prntJob As ManagementObject In prntJobCollection
            Dim jobName As String = prntJob.Properties("Name").Value.ToString()
　
            Dim prnterName As String = jobName.Split(",")(0)
            Dim documentName As String = prntJob.Properties("Document").Value.ToString()
      　    If String.Compare(prnterName, printerName) = 0 Then
                printJobCollection.Add(documentName)
            End If
        Next
        Return printJobCollection
    End Function

環境：VB.NET 2005、SPREAD for Windows Forms 5.0J

[確認]
MultilineをTrueに設定したテキストセルに、CRLF、CR、LFを含んだ値を設定する。

Dim txtMultiLineCellType As New FarPoint.Win.Spread.CellType.TextCellType
txtMultiLineCellType.Multiline = True

[結果]
CRLF、LFは改行されて表示される。

環境：VB.NET 2005 、スマートクライアント

<現象>
改行コードCRがLFに変換されている。

<参考サイト>

Webメソッドのstring型の戻り値に含まれる改行コードが変換されてしまう

WebMethod中の改行コード（CRLFがLFになっちゃう）

<戻り値の型>
今回、確認できたは、戻り値の型は下記
（１）戻り値がDataTableの場合は、改行コードが変換される。
（２）戻り値がDataSetの場合は、改行コードが変換されない。

テーブルに制約を指定していない為に、想定(意図)していない値が設定されて、
アプリケーションが正しく動作しないことがあります。
個人的には、（１）～(３)は、必ず指定して欲しいです。
（４）（５）は、設計はして欲しい。

（１）主キー制約（PRIMARY KEY制約）
　主キーのないテーブルは、原則だめ。※一時テーブルのみ可。

（２）一意キー制約（UNIQUE制約）
　代替キーを使用し、かつ、一意となる自然キーがある場合は指定する。

（３）NOT NULL制約
　NULLがだめな項目には必ず指定すること。

（４）CHECK制約
　意図している値があるなら指定すること。個人的にはあまり使用しない。
　アプリケーション側でチェックしている。

（５）参照整合性制約（REFERENCES制約）
　いろいろご意見あると思いますが、個人的には、設計時（ＥＲ図など）には指定しているが、
　実際のテーブル(物理構造)には適用していない。
　※レスポンス、メンテナンス、仕様変更などを考えると・・・・。

別名定義を確認するためには,

Get-Alias

を使用する。

自分の周りの話です。世間ではどうなのでしょうか？

データ件数を考慮していないで設計・開発する為、
まともに動かないものが多いです。

（１）実行計画を取得しない。
ＳＱＬが自分の思ったとおりに実行されているか確認しない。

（２）実際のデータ件数を想定しない。
データ件数を考慮しない、データ件数がどのくらいか知らないでＳＱＬを作る。
※ＳＥがテーブル設計時にデータ件数を考慮しない。

（３）セオリー(チューニング含む)をやらない。
ＷＥＢでも、書籍でも、雑誌でもやらないでねと書いてあることを平気でやる。
かつ、やろうねと書いてあることをしない。

（４）システム標準ルールを無視する。
・・・・。

（５）実行時間の計測をしない。
・・・・。当然性能要件を守れない。

環境：S2Dao.net + ODP.net(ORACLE)

<現象>
DBに接続できないとエラーがでた。

<原因>
(1)ODP.NETのPoolingがディフォルトでTRUEとなっている。
(2)ＤＢ接続時にプロファイルでリソース制限(IDLE_TIME)されていた。
上記(1)(2)の為、しばらくＤＢに接続しないでいると、プーリングされている接続が切断されてしまい
ＤＢに接続できなくなってしまった。

<対応>
(1)ODP.NETのPoolingをFALSEに設定。

※前提でリソース制限の解除はできない。

トリガは使いたいが、こんな事があった。

　・仕様変更をしたとき、トリガだけ修正漏れ。
　（仕様書のどこにもトリガを使用していること書いてない。）
　・トリガに限って仕様書ない。
　（別にトリガの問題ではない。）
　・運用を実施する人がトリガを知らない。
　・当該テーブルのデータをメンテナンスする時に、トリガが動くのを忘れてしまう。

なので、下記程度にとどめたい。
　・監査ログや、テーブルの履歴の作成みたいなの。

結論は、システム開発から運用まで考えて、
保守できる程度に使用すればいいかと思う。

（１）どのテーブルにも必要なカラム
　　「作成日」、「作成者」、「更新日」、「更新者」
（２）論理削除の場合に必要なカラム
　　「削除フラグ」、「削除日」、「削除者」
（３）世代（履歴）管理に必要なカラム
　　「使用（有効）開始日」「使用（有効）終了日」

（１）サロゲートキーの使用。
　・自然キーには、ユニーク制約をつける。
（２）正規化くずし。
（３）トランザクションへの値の埋め込み。
　・マスタデータが変更される場合、計算結果を格納する場合など考慮。
（４）削除の方針。
　・論理削除か物理削除するか。
（５）マテリアライズドビュー（Oracle）の使用。
（６）固有の値の作成にシーケンスの使用。