關於表格參考的問題（來自 Russel）
這個問題出現在關於“ Re: 2022Q1 Practical Session - Beginners" - 我也想讓其他人加入討論，所以我把它放到了討論論壇上。
關於您今天展示的表引用的問題：如果您作為腳本的一部分按順序處理多個表，您是無限迭代表引用（dt1、dt2、dt3...）還是有更智能的解決方案？
背景：我經常操作表（連接、連接、拆分等），有時我會依次打開、處理和關閉很多表，然後在同一個腳本中移動到下一個表，直到得到我想要的最終表.
回复：關於表格參考的問題（來自 Russel）你好@Ressel ,
這真的取決於你最終想要做什麼。 如果您有 100 個數據表，您想以相同的方式處理並在之後關閉，那麼循環（打開、處理、關閉每個表）可能比打開所有 100 個表然後再處理一個之後做得更好另一個。 一個原因是您沒有創建那麼多窗口句柄，這可能會在系統端引發另一個問題。
一般來說，我會在表變量名稱中更具描述性，所以如果有意義的話，我會更好地理解它是什麼。 “dt”主要用於骯髒的黑客；）
您還可以獲取所有打開的數據表，然後使用
Get Data Table List();
這可能是一個聰明的舉動。
其他人對此有何看法？
回复：關於表格參考的問題（來自 Russel）我同意@martindemel ，這取決於文件存在的位置、處理它們的順序以及要對它們做什麼。 JSL 在增強型日誌之外有許多可以提供幫助的內置函數。 例如，目錄中的文件為您提供目錄中所有文件的列表。 選擇文件讓您以交互方式從目錄中選擇一個或多個文件。 雖然增強型日誌在捕獲交互操作方面做得很好，但您仍然希望將硬編碼的表名引用替換為對錶的變量引用。 @martindemel展示了其中的一些使用dt = 打開（... 在大多數情況下，打開文件的 JSL 操作將返回創建的數據表的句柄。 當您使用來自表菜單。 例如，如果您正在創建一個子集，則語法
subsetDT = dt << Subset(...
將讓您捕獲對新創建的表的引用。 其他表操作以類似的方式工作。
回复：關於表格參考的問題（來自 Russel）感謝您的回复。 關於我正在使用的背景的更多信息。
我通過 ODBC 從我們的 Google Cloud Platform 實現中加載表。 這些表格會定期更新最新的製造數據。 例如，我加載的第一個表（我將其引用為dt ) 在不同的列中具有批次 ID、不同 QC 參數的參數名稱、測量結果和測量單位。 我按 QC 參數名稱拆分它（並將輸出引用為dt2 , 關閉dt ）。 然後，例如，我加載另一個表，該表交叉引用具有製造位置的批次 ID（我將其引用為dt3 ）。 之後我可以加入dt2和dt3 , 創建dt4依此類推，直到我有一個表格，其中包含我認為在進行任何分析之前需要的所有信息。 在某些腳本中，我正在處理近 10 個表，所有表都被引用為dt(n) . 這是我目前的技能水平所允許的。
我有一個中期計劃，將這樣的腳本用於控製圖表。 目前我只是直觀地評估趨勢並將屏幕截圖或 html 導出的圖表發送給不同的利益相關者。
我從這次談話中得到的是使用更具描述性的表格引用。 這些也是所謂的句柄？
回复：關於表格參考的問題（來自 Russel）描述性句柄/參考名稱將在某些時候幫助您（或其他必須修改您的代碼的人）。 當您可以使用 Show(dt_batchid_loc); 時，這也使調試打印更容易。例如查看創建的表名。
在創建表時使用輸出表（“表名”）也可能很有用。 如果您（當您）必須調試代碼時，這將對您有所幫助。 如果你不這樣做（我傾向於跳過這個，它會時不時地困擾著我），與 QC 的“Untitled 3041 summary”相比，從“BatchID_with_Loc”之類的名稱中查看哪個表打開要容易得多, Loc”什麼的。
回复：關於表格參考的問題（來自 Russel）也有可能在數據庫中進行表操作（例如查詢生成器或本地 SQL 中的查詢定義）。 這對於大型數據集是有利的，因為您可以避免流量並將重負載放到服務器上。 然後，您還需要在 JMP 中處理較少的表。
回复：關於表格參考的問題（來自 Russel）我之前嘗試過使用查詢生成器。 它非常緩慢，並且不斷崩潰。 所以我聯繫了 SAS 技術支持，但他們無法解決問題。 結果，我堅持在腳本中處理單個表，其中；考慮到查詢構建器的糟糕表現；更加方便和高效。 這可能是因為我正在加載的表有大約 100 000 多行 - 這至少是技術支持的結論。 唉，除了這些“巨大”的桌子，我幾乎無處可去。
另外，我認為我需要緊急熟悉調試。 雖然我設法“爭吵”了幾行有用的代碼，但我並沒有考慮架構、美學或；事實上;如何構建可以調試的腳本。 不幸的是，這對我來說仍然是一個陌生的概念。
