奇摩知識+回覆備份

http://tw.knowledge.yahoo.com/question/question?qid=1510030605719

 

Q:

我用ASP程式寫了一支線上發信的程式
我想擴充其功能
想做到定時發信的功能
目前的程式只能寫完信後
按發信
就傳出去了
我想讓它可以設定某年某月某日某時發送
或設定週期發送
如何銀行的定期轉帳功能
設計這種功能
ASP可以做的到嗎
還是要用啥語言開發呢

 

A:

您好;

姑且不論您用ASP作這樣的功能(定時發信)合不合理(我本人也建議用windows form 或console mode application 作比較好),單就技術上而言,是可行的。簡述方法如下:

假設您的ASP,檔名是 SendMail.ASP。

(1)將檔名更改為 SendMail.VBS (即將.ASP改為.VBS)

(2)程式中不可呼叫 ASP Object;例如:
-->如果有用到 "Server.CreateObject"的程式碼,請改為"CreateObject"
-->"Request"/"Response"等,都不可使用,請移除/修改程式碼。

(3)所有的程式,"必須全都是" ASP code, 也就是說,不可含有HTML Code 或 Javascript/VBScript

(4)移除所有 "" 記號。

完成後的程式,範例如下:
[SendMail.VBS]
==============================================
Dim objCDO

Set objCDO = CreateObject("CDO.Message")
With objCDO
.To = "您的(email address)"
.From = "您的(email address)"
.Subject = "Scheduling Test"
.TextBody = "Scheduling Test Body"

.Send
End With

Set objCDO = Nothing
==============================================

(5)執行(滑鼠雙擊)SendMail.VBS,測試是否如預期寄出信件。

(6)最後,以控制台的排程工具,依照您期望的時間,將VBS 排程。
(執行的程式,直接指向該VBS即可)

以上是基本的作法;如想獲得更多知識,您可以參考下面兩篇文章:

[Getting Scripts to Run on a Schedule]
http://www.asp101.com/articles/john/schedule/default.asp

[How do I schedule ASP files?]
http://classicasp.aspfaq.com/general/how-do-i-schedule-asp-files.html

cbw0731 發表在 痞客邦 留言(1) 人氣()

 

原文: Linked Server performance tips

 

重點摘要:

透過linked server 所執行的遠端存取/交易,可能耗用大量的頻寬,所以在使用上,要注意能避免的overhead 要盡量避免。

  

當查詢裡包括遠端主機的資料時,用linked server 將比使用 OPENROWSET OPENDATASOURCE 來得有效率。

  

當需要遠端主機回傳資料時,盡量讓資料先在遠端過濾完畢後再回傳;亦即,只取回必要的資料就好,以避免額外的網路傳輸。OPENQUERY 可作到這樣的效果。

 

當遠端 DB 與近端 DB character set sort order (collation) 相同時,可將 SP_SERVEROPTION "collation compatible"選項打開,可增加效能;尤其當使用 WHERE 時,若選項不開啓,則 MS SQL 必須將遠端所有資料傳輸至近端後才能比對;若開啓,則可在遠端比對。

 

遠端主機最好與近端主機接同一台 switch,或至少在同一個 subnet 裡。

 

當以 Enterprise Manager Management Studio 建立一個 linked server 時,在 Server Option tab 裡,可以考慮設定 Connection Timeout 以及 Query Timeout 的值;預設值 0 表示不會 time out,設定該值可以幫助我們找出效能不彰的 Query

 

 

 

在預設的情形下, MS SQL 會將查詢盡量放在遠端,並只取回必要的資料, 但在下述情形下, MS SQL 可能必須先將所有資料取回:

  • Data conversion operations (eg: cast/convert)
  • 當用到 bit timestamp uniqueidentifier 等資料型態
  • 用到 "TOP" keyword
  • INSERTS UPDATES DELETES
  • 所以最好避免執行上述的遠端查詢/交易

 

最後, 善用 Query Analyzer 查看 query plan 以確保大多數的資料查詢是在遠端上執行,而非近端 DB

cbw0731 發表在 痞客邦 留言(0) 人氣()

原文 - http://www.sqlteam.com/article/temporary-tables

暫存表(Temporary Tables)

CREATE TABLE #Yaks (
YakID int,
YakName char(30) )
  • table name 前加入"#", 表示這是一個暫存表(temporary table)
  • 當session 關閉時, 這個table 將會自動drop
  • 好的寫作習慣, 應在暫存表使用完畢後, 下指令去 drop, 而不是讓系統自動回收
  • 暫存表是存在主機記憶體中, 因此存取速度較快
  • 暫存 table 的限制:
  • 暫存表存在於"tempdb"這個database 裡
  • 如果有兩個使用者建立同一個名字的暫存表, 則他們會各自擁有獨立的一份, 互相不會干擾.
  • 若stored procedure A 建立了一個暫存表, 並呼叫 stored procedure B, 則在 B 中可以存取這個暫存表
  • 如果在SQL Server Management Studio or Query Analyzer 中建立的暫存表, 會等到我們手動drop 去關閉session 才會消失

 

表格變數(Table Variables)

當我們使用 SQL Server 2000 或以後的版本, 則可以考慮使用 "Table Variables" (表格變數); 使用方式如下例:

DECLARE @TibetanYaks TABLE (
YakID int,
YakName char(30) )

INSERT INTO @TibetanYaks (YakID, YakName)
SELECT YakID, YakName
FROM dbo.Yaks
WHERE YakType = 'Tibetan'

-- Do some stuff with the table

 

 

  • 它和暫存表類似, 但它更加彈性, 且不會存在於tempdb 中(完全存在於記憶體).
  • 使用完畢後, 不須手動去 drop它

 

兩者的使用時機

 

  • 當暫存的資料筆數小於100筆時, 使用表格變數, 否則, 可使用暫存表, 因為針對表格變數, SQL Server 不會去解析/最佳化它的效能.
  • 當我們須要對表格建立索引(Index)時, 則必須使用暫存表.
  • 在使用暫存表時, 最好能在建立後一併建立索引, 這能增加效能 (SQL Server 2005後, 這方面已改善, 所以可以不建索引; 但建立它仍是一個好習慣)

 

全域暫存表(Global Temporary Tables)

在表格名字前面, 加入兩個"#", 比如"##YakHerders", 則表示這是個全域暫存表, 也就是說, 這個表格和一般表格一樣, 可以被所有連線(connections/sessions)使用; 在SQL Server 中, 這樣的應用並不多見.

cbw0731 發表在 痞客邦 留言(1) 人氣()

原文 - http://www.sqlteam.com/article/sql-server-versions

 

SQL Server 版本一覽 (2010/1/18為止)

 

SQL Server 2008
10.00.27.57 SQL Server 2008 SP1 CU6 18 Jan 2010
10.00.2746 SQL Server 2008 SP1 CU5 24 Nov 2009
10.00.2734 SQL Server 2008 SP1 CU4 22 Sept 2009
10.00.2723 SQL Server 2008 SP1 CU3 21 July 2009
10.00.2714 SQL Server 2008 SP1 CU2 18 May 2009
10.00.2710 SQL Server 2008 SP1 CU1 16 Apr 2009
10.00.2531 SQL Server 2008 SP1 7 Apr 2009
10.00.1828 SQL Server 2008 RTM CU9 18 Jan 2009
10.00.1823 SQL Server 2008 RTM CU8 16 Nov 2009
10.00.1818 SQL Server 2008 RTM CU7 21 Sept 2009
10.00.1812 SQL Server 2008 RTM CU6 21 July 2009
10.00.1806 SQL Server 2008 RTM CU5 18 May 2009
10.00.1798 SQL Server 2008 RTM CU4 17 Mar 2009
10.00.1787 SQL Server 2008 RTM CU3 19 Jan 2009
10.00.1779 SQL Server 2008 RTM CU2 17 Nov 2008
10.00.1763 SQL Server 2008 RTM CU1 22 Sept 2008
10.00.1600 SQL Server 2008 RTM 6 Aug 2008
SQL Server 2005
9.00.4285 SQL Server 2005 SP3 CU8 16 Feb 2010
9.00.4273 SQL Server 2005 SP3 CU7 21 Dec 2009
9.00.4266 SQL Server 2005 SP3 CU6 19 Oct 2009
9.00.4230 SQL Server 2005 SP3 CU5 17 Aug 2009
9.00.4226 SQL Server 2005 SP3 CU4 16 June 2009
9.00.4220 SQL Server 2005 SP3 CU3 21 Apr 2009
9.00.4211 SQL Server 2005 SP3 CU2 17 Feb 2009
9.00.4207 SQL Server 2005 SP3 CU1 20 Dec 2008
9.00.4053 SQL Server 2005 SP3 GDR (Security Update) 13 Oct 2009
9.00.4035 SQL Server 2005 SP3 16 Dec 2008
9.00.3356 SQL Server 2005 SP2 CU17 21 Dec 2009
9.00.3355 SQL Server 2005 SP2 CU16 19 Oct 2009
9.00.3330 SQL Server 2005 SP2 CU15 18 Aug 2009
9.00.3328 SQL Server 2005 SP2 CU14 16 June 2009
9.00.3225 SQL Server 2005 SP2 CU13 21 Apr 2009
9.00.3315 SQL Server 2005 SP2 CU12 17 Feb 2009
9.00.3310 SQL Server 2005 Security Update 10 Feb 2009
9.00.3301 SQL Server 2005 SP2 CU11 15 Dec 2008
9.00.3294 SQL Server 2005 SP2 CU10 20 Oct 2008
9.00.3282 SQL Server 2005 SP2 CU9 18 Aug 2008
9.00.3257 SQL Server 2005 SP2 CU8 16 June 2008
9.00.3239 SQL Server 2005 SP2 CU7 14 April 2008
9.00.3233 SQL Server 2005 QFE Security Update 8 July 2008
9.00.3228 SQL Server 2005 SP2 CU6 18 Feb 2008
9.00.3215 SQL Server 2005 SP2 CU5 17 Dec 2007
9.00.3200 SQL Server 2005 SP2 CU4 15 Oct 2007
9.00.3186 SQL Server 2005 SP2 CU3 20 Aug 2007
9.00.3175 SQL Server 2005 SP2 CU2 28 June 2007
9.00.3161 SQL Server 2005 SP2 Cumulative Update 1 (CU1)  
9.00.3152 SQL Server 2005 SP2 Cumulative Hotfix 7 Mar 2007
9.00.3077 SQL Server 2005 Security Update 10 Feb 2009
9.00.3054 KB934458 - Also read Bob Ward's post on SP2. 5-Apr-07
9.00.3042.01 SQL Server 2005 "SP2a" 5-Mar-07
9.00.3042 SQL Server 2005 SP2 Feb-07
9.00.2047 SQL Server 2005 SP1  
9.00.1399 SQL Server 2005 RTM Nov-05
SQL Server 2000
8.00.2039 SQL Server 2000 SP4  
8.00.760 SQL Server 2000 SP3  
8.00.534 SQL Server 2000 SP2 30 Nov 2001
8.00.384 SQL Server 2000 SP1  
8.00.194 SQL Server 2000 RTM  
SQL Server 7
7.00.1063 SQL Server 7.0 SP4  
7.00.961 SQL Server 7.0 SP3 15 Dec 2000
7.00.842 SQL Server 7.0 SP2 20 Mar 2000
7.00.699 SQL Server 7.0 SP1 July 1999
7.00.623 SQL Server 7.0 / MSDE 1.0 RTM  
SQL Server 6.5
6.50.416 SQL Server 6.5 with Service Pack 5a  
6.50.415 SQL Server 6.5 with Service Pack 5  
6.50.281 SQL Server 6.5 with Service Pack 4  
6.50.258 SQL Server 6.5 with Service Pack 3  
6.50.240 SQL Server 6.5 with Service Pack 2  
6.50.213 SQL Server 6.5 with Service Pack 1  
6.50.201 SQL Server 6.5 RTM  
  • 查詢版本的指令
Select @@version

查詢結果如下(以我的環境為例):

Microsoft SQL Server 2005 - 9.00.3077.00 (Intel X86)

Dec 17 2008 15:19:45

Copyright (c) 1988-2005 Microsoft Corporation

Enterprise Edition on Windows NT 5.2 (Build 3790: Service Pack 2)

 
  • 查詢相關資料的系統 sp:
exec master..xp_msver

 

cbw0731 發表在 痞客邦 留言(0) 人氣()

業界對公司的資訊系統的導入,普遍存在一個奇怪的現象:「別人有什麼,我也要有,否則就是沒競爭力!」

前兩天聽一位高階主管說:「你們MIS 看看同行的xx電子,他們什麼都有! ERP /CRM/SCM/MES /RMA/……我們怎麼跟對方比?」

隨著公司的成長,我們會陸續導入各種系統:採購部為了提昇效率,會要求要導入e-Procurement(電子採購);客服部為了提高客戶滿意度,要導入CRM(客戶關係管理)及RMA(售後服務及維修管理);業務部可能應客戶稽核的要求,要導入MES或SFCS(製造執行系統/產線控制系統)…… 這些熱門的系統,動輒7位數甚至8位數以上的花費,加上大量的人力投入,快的話半載,慢的話一兩年才上線,所帶來的效益,卻大多實現於該需求單位,其他部門可能只是「聽說過」有這麼一件事,對他們來說,幫助幾乎等於零。

上述現象,並不代表導入這些系統是錯誤的,只是以「對公司的邊際效益最大化」(或最大C/P值)來說,往往卻比不上下述三項的貢獻:

1. Mail / FTP / File Server /Fax Server / VoIP / ......
2. EIP (查分機、訂便當、訂會議室、請假、發公告、查詢公司規章制度……)
3. User 電腦操作教育訓練

看到這,可能很多人要大呼上當了?「這些我們早就有了呀!」

有歸有,但品質如何?

Mail/FTP/.. 等,達到99.99%以上的服務比率(Service available rate)了嗎?
-->不要小看這個數字,若能達到,則網管的功力及經驗也必定大幅提昇

EIP 裡的功能,足夠幫助員工,使其能專心於專業項目的發揮而不用煩心於一些辦公室的瑣事嗎?
-->等於人人都有一位不會累的助理

員工的電腦程度,夠「高竿」嗎?
-->有沒有人去算過,如果每位員工都會操作 MS Windows 裡的熱鍵,如Ctrl-C/Ctrl-X/Alt-F4/…… 將會提高整個公司多少工作效率嗎?如果他們都知道不能開啟來路不明的網頁或檔案,會減少多少資安上的問題?

千萬不要小看它這些所謂的 OA(辦公室自動化);如果能把這些項目作好,所產生的綜效,比很多麗而不實的系統大得多了!以長遠來看,管理者應把它們視為「紮馬步」的基礎功,只要馬步穩了,學其他功夫自然事倍功半!


所以親愛的主管們,在出發到遠眺的那片美景之前,是否停下腳步,看看自己的食糧是否充足?體力是否足夠?

cbw0731 發表在 痞客邦 留言(0) 人氣()