Compute欄位小計異常

-
請問一下,為什麼我在這個DW的[總成本小計]後面的COMPUTE欄位(如下圖所示)加入sum( compute_0024 for group 1 )

但出來的結果卻是
我是很單純的想把COMPUTE_0024加總起來而已!!好怪
********************************************************************************
關於Compute的問題，我也遇過幾次，原因不是很清楚，但是有些做過調整後就可以使用了，我提供幾種解決方法你可以各個去試試：
  1. compute_0024有Null值，因為某些條件下沒有計算值，我推測是Null值，這個Null值可能導致Group1上的compute計算sum值錯誤。解決方式：在compute_0024的公式外面加個if(isnull(xx) , 0 , xx)的判斷，強迫讓Null值的公式出現0值，缺點：畫面上會有"0"值出現。

  2. 在Group1上的compute公式中加入isnull判斷sum(if(isnull(compute_0024),0,compute_0024) for group 1)，這方法不會有第一點的問題，但是如果是compute_0024值有問題，依然不能解決。

  3. 在Group1上的compute公式中不要直接使用compute_0024這種計算欄位的值，直接將compute_0024中的公式拿來替代compute_0024，因為經過測試發現計算欄位有時候去取得其他計算欄位的值時會有異常值的出現(原因不明，我猜可能是PB內部運算順序導致)，因此我發現這樣雖然公式會"落落長"但是比較不會有問題。

  4. Compute欄位的format不要使用預設的這個也是特例問題，雖然系統在不指定下會使用[general]，卻有時候會發生計算小數點的錯誤問題，通常這種錯誤都會只發生在小數點下，我的經驗是有時候去TOTAL整數卻會跑出一堆小數點以下的數值，修改過FORMAT後就好了。例如僅需要整數時把FORMAT設定:###0。

以上四點是我這邊解決compute field的經驗，你可以修正試試看。

留言

Vasili寫道…
試過更新 EBF 嗎？
2011年9月3日 下午3:50
WILDOX寫道…
to Vasili:
這是我朋友提出的問題，他的版本是PB6.5,
這是我當初幫他解決的方式，
我想應該很難找到EBF了吧‧
2011年9月5日 下午4:35
張貼留言

這個網誌中的熱門文章

【研究】列印的條碼為什麼很難刷(掃描)

-
圖片
條碼在我們的世界無處不在，小至發票，大至大型裝置設備都會有它的身影。 每一家有制度化的公司，多少都會需要用到條碼來進行管理，身為開發人員，就很難不會碰到它。 但是我們常常因為不熟悉條碼的規則，而導致作出來的條碼沒辦法被讀取(掃描)，也常遇到A設備可以讀取，B設備就無法讀取的奇怪現象，當然讀取設備本身的讀取元件也是有功力上的差別，有些廠商有能力可以調教讀寫元件的設定。 接下來，我就做點實驗給大家知道這個條碼的問題出在哪裡，以便在往後使用條碼時可以更注意到發生的原因。 在這裡我不再重述條碼的來由，這次的比較是使用大家常用的Code39(又稱39碼)來比較。 使用39碼得主要是因為他有字型檔可以使用，可以拿來做比較。 條碼的列印方式分類與優缺： 一、由條碼機(又稱標籤機)內建指令列印 優點：線條清晰，掃描讀取容易、速度快。             列印特殊紙張(背膠式、連續型.....) 缺點：特殊的指令語言(每一個廠牌都不太一樣)，等於換機器就要改寫程式碼。             有一些貼心的廠商(精聯)會提供比較簡單的統一語言列印工具，減少開發者困擾。             版面變化較少，沒有視覺化編輯。 二、由Windows Driver列印，或稱普通列印 優點：只要有驅動程式就可以列印，不需要改寫程式(或改寫幅度小)。            版面彈性比較自由。由於只要有驅動就可以列印，            所以比較不限定紙張種類，或印表機種類。 缺點：列印線條有很多模糊地帶，沒控制好就會導致無法讀取。            受到列印裝置解析度限制，匹配沒做好就會失敗。 底下先做出三種情境比較： 雷射印表機：600DPI 條碼印表機(標籤機)：203DPI 這裡，我們先 比較印表機解析度的列印差異 ，請忽略機器種類。
裡面更多內容 》》》

統一發票列印小程式

-
圖片
1、請注意本版留言過多， 您的留言可能不在這一頁，請到以下留言樓層看看再回應喔～  2、如果您有填寫表單，卻沒有收到我的郵件，有可能您填寫的電子郵件有錯誤，麻煩您查看一下留言是否有我給您的信息喔。因為我沒辦法直接連繫到您。 1 ~200 則，請按這裡   200+ 以上請按這裡 因為公司會在一堆系統上都有可能要印發票(真不懂要怎麼搞?) 希望可以有個小工具可以列印電子發票， 原本發票列印程式要使用條碼機專用語言(ZPL、EPL)，但容易被某種機型綁定。 當然可以考慮使用ESC/POS指令的方式，但也是要印表機支援這種指令列印模式(當然多數表機都有支援)，不過要列印QR碼，就有點不是那麼容易了，除了要自己編碼外還要注意中文問題。 後來我想改用Windows Printer Driver來列印，雖然不如指令式快速，但可以方便各類型程式應用，因此考慮了以下的條件： 使用C#開發、.Net 2.0平台、Console呼叫 本來想用RDLC來做，但是很不幸的，失敗了，原因就在於條碼， 國稅局訂定的Code39條碼內要放入21個字元(19+2)長度， 如果使用RDLC的話，解析度只有100DPI，密度不夠，條碼線條沾黏嚴重。 一般的條碼機至少都有200DPI得等級，這RDLC也太彆腳了吧， 網路上找盡RDLC條整解析度的方式都沒有比較好的效果。 因此，改用直接C#繪製的方式來做， 當然中間為了條碼圖像清晰度的問題花了不少心力解決。 下載點： PrintInvoice
裡面更多內容 》》》

C# 使用 Process.Start 執行外部程式

-
圖片
C# 執行外部程式的方式並不難，也很簡單，首先引入 using System.Diagnostics; 然後使用 Process.Start( "OtherProgram.exe" ) 方式就可以呼叫並執行。 但是，某些情況下會導致程式無法被執行(或是無法正常執行)， 很多原因在於『執行程式的起始位置』，由於被呼叫的程式執行時， 它所啟動的路徑其實是在呼叫程式的路徑下， 如果被呼叫程式需要讀取與程式相同路徑下的文件檔案(或是INI)，可能會導致找不到的問題。 為了測試這樣的現象，我準備了2支程式， 一支是被呼叫端的程式 HelloConsole.exe 另外一支就是呼叫端程式 CallOtherProgram.exe HelloConsole.exe 這支程式 在啟動時會讀取相同路徑下的 Doc.txt 並將內容顯示出來，如果有參數也會把參數列出來。而這支程式我固定放在 D:\TEST\ 下，以方便測試，如果不是在這路徑下，那呼叫端的程式碼裡面的路徑也要變更。 HelloConsole.exe using System; using System.IO; namespace HelloConsole {     class Program     {         static void Main(string[] args)         {             Console.WriteLine("This is HelloConsole.exe");             Console.WriteLine(" ");             Console.WriteLine("Environment.CurrentDirectory is ");             Console.WriteLine(Env...
裡面更多內容 》》》