一直以來，我發現保存過程，是我們開發軟件最花時間的部分，且經常出錯，檢查代碼需花很多時間。
例如這種界面，我們一般是先判斷哪些值不能爲空，然後拷貝到..\test.dbf，pack後，再獲取每個值的變量，再寫SQL插入語句，返回成功後，我們處理好界面。
其實基本每個界面都做着同樣的事情。代碼也很長，（我計算了下，這樣的界面，代碼最少要80行）。但每次修改或者增加字段的時候，就需要動很多地方，特別是，當字段特別多的時候，需要修改的代碼特別多，而且容易出錯。先本地臨時表dbf，然後SQL數據庫（這2個是必須的），然後保存代碼再增加。我見過最多代碼的的表單，染色加工單，因爲工藝複雜，單個表單的字段超過120個，SQL插入語句要分5句才能完成。（VF不允許一行語句特別長）。
爲了解決這個問題，我曾爲自己開發了SQL代碼生成器。
只要選擇好要保存的dbf表，字段和插入語句和修改語句是自動生成的，我甚至還做了，當字段超過10個的時候，就換成先插入，再修改的方法。
我把DBF的每個字段獲取到變量a1，a2,a3........
然後生成我們那句 ln1 = SQLEXEC(lnHandle,"inster into [表名] (字段，字段...) values (?a1,?a2...)。
用這個工具，能減少很多時間，出錯率也降低了很多，但還是花費很多時間寫保存過程，因爲保存代碼會隨着字段的多少而增加，這種方法在遇到特別多字段的時候，或者需要經常修改字段的時候，工作量極大，我在這方面吃了很多虧。畢竟我經常是接定製開發的客戶訂單，龐大工作量，花費很長的時候，會讓我客戶失去耐性。
於是，我嘗試使用視圖，但是，很不實際，ODBC很經常受其他軟件影響經常需要重建，win10後，需要管理員權限才能穩定。而且，做連接的時候，也需要挨個表單填寫連接填寫清楚。當然，確實方便，只是穩定性，就不好說了。
我再把方向改到CA類，但是，學習曲線大。我繼續找，其實網上很多做好的框架，但都沒有中文教程，最後找到加菲貓的，但加菲貓的東西，脫離了dbf，需要自己寫保存語句，當然也很快，但是，代碼沒有視圖那麼簡潔，修改起來，還是要動代碼。
最後最後，我決定自己開發適合自己的，就是slqhelp類。保存代碼大概這樣，
代碼大概15行，保存和修改保存在一起。而且，不管你多少字段，都是這麼多代碼。那很多人會說，如果我不使用自增型ID，可以嗎？可以，但數據結構要這樣
基本就OK，放心，我做了無數個測試，遲點會把這個prg放到網上免費下載。能找到出錯的部分，我解決不了的，加我微信，我發紅包給你。我之所以信心滿滿，是因爲我中間這個函數的方式，跟我原來最穩定的spt保存方式一樣，只是，我做成自動生成的方式了，這部分我抽出來做中間層，只需要把你要保存的數方到test.dbf，然後運行sqlhelp（）函數，即可。