記憶體清除 ( Garbage collection )
記憶體清除在做些什麼事
何時會執行記憶體清除的工作
記憶體清除的例外處理
全球最大企業暨行動軟體領導廠商Sybase(NYSE: SY)宣佈，PowerBuilder® 12開始供貨。這個新一代、得獎肯定的快速應用開發工具軟體，讓開發人員以更容易、快速且具成本效益的方式，建立或轉移他們的商業應用到Microsoft .Net Framework，以徹底現代化與視覺化技術，創造有吸引力的應用使用者經驗。
「多年來，Sybase PowerBuilder一直做為應用開發生產力的堅實堡壘，讓各種等級的企業應用以高生產力的圖形使用者介面(GUI)，結合重量級的資料庫導向。」IDC應用開發軟體研究部門的方案協理Al Hilwa表示：「PowerBuilder把Virtual Studio介面納入自己的基礎架構，成為一個無縫的Windows .Net環境。這種做法意味著，它現在可以被公平地考慮用來發展既有系統，也能用來開發兼容於Windows 32環境和.NET的新系統。」¹
嶄新的Sybase PowerBuilder 12架構搭配Microsoft的Virtual Studio基礎架構，為在.NET Framework環境中的PowerBuilder開發人員，提供最高等級的應用開發生產力。PowerBuilder 12仍舊只需要五行程式－取代其他語言工具的上百行程式－就能使用它專利的DataWindow®科技存取強大的商業邏輯。有了重新以C#改寫過的DataWindow，PowerBuilder 12也能產生管理式程式碼，並原生支援Microsoft新一代展示層架構(WPF)，讓開發人員甚至更有生產力、彈性與安全性。此外，PowerBuilder 12也是目前唯一的產品，能讓客戶續用他們既有Win 32程式碼，並無縫轉移到.NET Framework，節省因改寫程式衍生的費用和複雜性。
今天在網站上找到一篇文章是關於逢甲大學中央廚房管理系統在Web上的實作。
工具軟體：PowerBuilder
* 設計及部署中介層的元件及撰寫其相關的邏輯程式。
* 設計DataWindow 供瀏覽器使用。
* 提供客戶端(Client)與伺服器端(Server)與中介層溝通的元件。
我是一個開發者，自由或者被迫選擇平臺是沒有辦法的事情，而且不是說只能選擇一個平臺開發自己的運用，我們受到多種因素的響，比如流行度，客戶接受情況，成本，開發平臺和工具的優劣。這個好像是市場行為，業已形成，就好像颱風來了，它往東吹，你就沒法往西邊跑。
要選擇成本小的，客戶歡迎和接受的，穩定和流行的平臺和工具，這是沒得說的。
成本小，體現在開發上，容易開發和修改，後期容易維護，客戶接管後也容易管理，不能說讓客戶要招專家進公司才能接管系統和再開發，那也不行。如那樣，恐怕你的錢都收不回來，因為你根本無法交脫手。因實際情況而定，無以特例概全面。程式開發每天都面臨反反復複的修改和一遍又一遍的升級。這當中有多少成本根本就沒納入計算，也難怪很多公司都沒有加班費，可能嚴格算起來開軟體公司是虧本的事情。以現在廣州深圳5000-6000奈何都招不到合適的人。如果你開公司說要給職員良好的待遇，什麼都按規定來，請問你會不會虧本。
java空中樓閣消散後，許多人又回到.net平臺開始招兵買馬，幹得轟轟烈烈。當然許多做 ERP的公司不一樣，我記得大概是2004年吧，我去宏遠酒店參加一家 ERP廠商的產品推介會，該廠商已經有用.net開發完整的產品了。也就是說準備期是在2002-2003年，足見走在.net運用的前面。定位的消費群體不一樣，我們好多產品註定只能呆在win平臺而無法去享受咖啡開發的優雅。
剛才搜網路，有人罵Delphi就像是一個不節食的大肚子，要不是生一個怪胎，要不是就是把肚子撐爆。其他語言也一樣，總有它發展的一個過程，到最後就是想門門包含，門門精通，豈不知，這世上都是物極必反，任何語言都有他的定位，這種定位會在一定時間的運用之後就凸現出來，會形成他自己的門戶和黃金搭檔。這麼說的話，PHP支持OOP也許又是一個孕婦。網上有論，java也是想包攬一切開發和一切平臺，不過，現在他定位企業運用開發和跨平臺移動開發等是比較不錯的，今天還沒有誰能代替他在這些方面的地位。
Powerbuilder現在成為sap家族的一個工具，廣大使用pb的人士可能忐忑不安，本身12剛出來還沒穩定，就出現這樣子的事情。通常使用者心底都希望自己的工具是一個保持獨立的產品。LAMP能說明這種情況。
我預見，sap作為企業運用的集大成者，整合sybase在業界看來是件好事。我認為也如此。
erp+資料庫+平臺也是其他幾家集團已經整合完成的一個模式。ms，ibm，oracle。都說四家天下。相形之下，sap在db方面是沒有話語權，或者說一張結實的桌子只有桌面子，沒有四條腿。而sybase恰恰是有四條腿的桌子，反而沒有一張結實的桌面子。這二者結合不能說不是件好事。做技術必須要強大的現金流來支撐，就如google的運用做得好一樣，因為他有強大而及時的現金流，google的科學家一點都不用考慮公司沒錢。ms在開發方面也是以萬人投入，其力度是相當大的。以至於就算我們坐上和諧號也追趕不上他家的技術進步。當然我們不能說sybase就缺錢。但是我自身說，sybase比較缺投入。但凡看在眼裡的事情都說明這個問題。如果連一個分割條都不屑一顧的話，如果幾個古板的控制項就可以糊弄近十個版本的話，那請問到底是缺什麼。
最新版Powerbuilder混淆器，在全世界得到近200個有效下載量(指知道什麼叫混淆的人下載它並細心測試它)，並得到較多品質較好的回饋，在此感謝大家支持這個一個遲來的工具，還好世界很大，從google的group上看有澳大利大，黎巴嫩，法國西班牙的用戶很多，否則就國內這麼點用戶，怕是我這個工具也是白寫的了。下載請至: http://chengg0769.download.csdn.net/
The roadmap that Sue Dunnell displayed was basically the same ose they showed during the Developer Days tour. It was updated a bit, it showed a 12.1 maintenance release in September of 2010 that would provide:
3rd party plugin support
ASE 15.5 and SA 12.0 support
Win7 64 bit OS support
XAML editor enhancements
IDE enhancements
WPF DW Right to Left
OLE support in WPF
The reference to 64 bit Window 7 just means it will be a supported platform for development and deployment. The IDE will still be 32 bit, as will the generated applications.
The OLE support in WPF is migration only, you won’t be able to add additional OLE references in the migrated application.
It also shows 12.5 release for July 2011 with the following:
本貼來自昕晨論壇轉載
併發能力是指多用戶在同一時間對相同資料同時訪問的能力。一般的關係型數據庫都具有併發控制的能力,但是這種併發功能也會對資料的一致性帶來危險。試想若有兩個用戶都試圖訪問某個銀行用戶的記錄並同時要求修改該用戶的存款餘額時,情況將會怎樣呢?我們可以對PowerBuilder中的DataWindow進行設置來進行併發控制。所謂併發控制就是指在用戶資料修改的過程中保證該資料不被覆蓋或改變的方式,在下面的例子中我們將看到如何設置DataWindow來控制開發訪問。為了說明問題,我們舉這樣一個簡單的銀行系統中的例子,某用戶的存款狀況如右:
我們假設事情的經過是這樣的:公司的某員工在銀行前臺取款2,000元,銀行出納查詢用戶的存款資訊顯示銀行存款餘額20,000元;正在這時,另一銀行帳戶轉帳支票支付該帳戶5,000元,機器查詢也得到當前用戶存款20,000元,這時銀行的出納員看到用戶存款超過了取款額,就支付了客戶2,000元並將用戶存款改為18,000元,然後銀行的另一名操作員根據支票,將彙入的5,000元加上,把用戶的餘額改為25,000元,那麼資料庫管理系統是否可以接受這些修改呢?
在DataWindows的設計中,我們選擇功能表Rows|Update…,會出現SpecifyUpdateCharacteristics的設置視窗,在這個視窗中我們設置Update語句中Where子句的生成,以此來進行開發控制。在這裏有三個選項,我們分別看一看在本例中這三個選項的結果:
(1)Key Columns:生成的Where子句中只比較表中的主鍵列的值與最初查詢時是否相同來確定要修改的記錄。在上述的例子中,轉帳支票的操作將覆蓋出納員作出的修改,這樣銀行損失兩千元。
(2)Key and Updateable Columns:生成的Where子句比較表中主鍵列和可修改列的值與最初查詢時否是相同。在上例中兩次查詢出的結果都是有兩萬餘額,當第一個人修改餘額時,餘額仍是二萬元,所以修改成立,而支票轉帳操作時餘額已不是二萬,所以該列不匹配,修改失敗。
(3)Key and Modified Columns:Where子句比較主鍵和將要修改的列,在本例中,結果與Key and Updateable Columns的選擇相同,因為餘額已改變,不再與最初的查詢相同,因此仍然不能修改。
讓我們作另外一個假設,我們把銀行後臺作支票轉帳操作改為凍結用戶存款,即把狀態欄位的值改為凍結,而且事件發生的次序如下表,那麼表中的次序4…前臺出納的修改能不能成立呢:
1.Key Columns:Where子句只比較主鍵值,顯然出納員的修改是允許的。
2.Key and Updateable Columns:生成的Where子句包括比較所有可修改的列,因此出納修改時Statue欄位為凍結與出納查詢時的tive不符,修改失敗,同時顯示錯誤資訊。
3.Key and Modified Columns:Where子句的比較包括主鍵和要修改的列,由於本列中修改列仍為20,000元沒有變化,所以出納的修改可以成立。
在本例中,我們可以看到Key and Updateable Columns的選項最嚴格,可以避免出現狀態列發生改變時餘額作修改的錯誤,但是這也會禁止我們作一些本當允許的併發修改,如出納修改存款餘額,而業務員修改用戶的聯繫地址等。因此我們應當根據實際情況,選擇適當的Update設置。
在SAP完成對Sybase收購前，Sybase的客戶和合作夥伴現在的日子有點難受，Sybase的技術
和產品未來將會如何發展，充滿著變數，就如同Sun被Oracle收購時，很多人對MySQL的未來
充滿了擔憂一樣，雖然如此，但本次SAP收購Sybase的有些問題是很容易理清的，至少不用
提心吊膽。
SAP是在上週三宣佈以58億美元收購Sybase的，交易完成後，SAP計劃將Sybase作為一個
獨立的品牌運營，這與2008年收購商業智慧廠商Business Objects的策略一樣，現在客戶最
希望聽到的是SAP對兩家公司的未來計劃，Forrester市場研究公司資深分析師Paul
Hamerman如是說。
SAP收購Sybase主要圖的是它的移動技術平台和數據庫技術，但也將同時獲得開發工具
PowerBuilder，Sybase通過努力現在PowerBuilder可以直接開發.NET程式，但現在問題最多
的也是PowerBuilder，很多人都擔心PowerBuilder會走向沒落。
來自Forrester的另一位分析師Jeffrey Hammond說：「PowerBuilder曾經是一顆搖錢樹
，我認為SAP不會改變Sybase一直以來對PowerBuilder的策略，至少不會立即改變，但問題
是在.NET開發工具離散的市場中，它對SAP是否還有保留的意義」。
//
位於休斯頓的Intertech顧問公司是Sybase的重度用戶，Intertech的總裁Don Clayton
說：「如果SAP不剝離PowerBuilder等產品，可能會更好。有很多公司的關鍵業務系統都是
用PowerBuilder開發的，我認為它是一個優秀的技術，我對本次收購持謹慎的樂觀態度」。
powertothebuilder.com站長兼WerySoft總裁Brad Wery 說：「我主要希望的是，SAP讓
Sybase繼續干他們未完成的工作；我最關心的是，人們在等待官方宣佈PowerBuilder未來的
公告前，已經被迫轉移到其它平台了。對於任何收購都一樣，我們現在已經著手為最壞的情
況做準備」，WerySoft主要產品是數據庫開發工具，與PowerBuilder的落寂相比，Sybase的移動平台就穩當多了，SAP收購Sybase的重點也就是其移動技術平台。
自消息散佈開來以後，Hammond就不斷收到來自Forrester客戶詢問有關Sybase移動技術
平台的電話，電話都被打爆了，Hammond說：「移動是未來最熱門的增長領域之一」。
Monash市場研究公司的Curt Monash說：「就Sybase的數據庫而論，其前景仍然不夠明
朗」。
一個可能的結果是SAP從此以後將不再推自家的MaxDB數據庫，MaxDB曾經是許多SAP客戶
的選擇，Monash說：「SAP將來極可能加大對Sybase ASE的投入」。
SAP在記憶體數據庫方面也可能做過頭，它將從Sybase獲得更多，Monash說：「構建數
據庫產品本身很艱難，但一個合適的數據庫技術應該是它的適用性非常好，SAP曾經在這方
面犯過錯，如果在Sybase上再犯同樣的錯誤，那將是非常之不幸」。
一位名叫Kevin Sherlock 的數據庫管理員說：「我們希望我們的Sybase數據庫職業生
涯可以繼續，希望SAP不要停止發展Sybase數據庫，讓它繼續蓬勃發展，繼續壯大」，他和
其他Sybase數據庫用戶組成員一樣，他們希望SAP將Sybase數據庫集成到他的核心產品套件
中。
但Altimeter集團合作夥伴的分析師Ray Wang認為，這幾乎是不可能的，SAP將會不折不
扣地拋棄Sybase的許多產品。他說：「確實找不出原因一個軟體廠商要滅掉自己的產品，除
非沒有足夠的用戶支付維護費用，顯然Sybase還沒有落魄到這種地步」。
SAP繼承Sybase有利可圖產品的同時也繼承了Sybase的挑戰。Sybase在教育用戶方面的
策略可以說是失敗的，一位不願透露姓名的老用戶說：「人們不選擇Sybase產品的一個主要
原因是找不到合適的技術人才」。
本次收購結束後的道路也會不平坦，SAP收購Business Objects完成後就出現過問題，
當時Business Objects的所有客戶都轉移到SAP的支援系統後，出現了很長一段時間的不適
應。51CTO數據庫頻道也認為，對於Sybase的收購案，我們還需要繼續觀察一段時間。
這些用戶對SAP本次收購可能也高興不起來。
PB 家族公佈欄 (2)