Just to give you some perspective on relative performance BASE dataset vs. XML dataset: libname x_test xml '/folders/myfolders/test.xml'; data x_test.bweight; set sashelp.bweight; run; proc freq data=sashelp.bweight; tables married; run; proc freq data=x_test.bweight; tables married; run; libname x_test clear; Log from that: 73 libname x_test xml '/folders/myfolders/test.xml'; NOTE: Libref X_TEST was successfully assigned as follows: Engine: XML Physical Name: /folders/myfolders/test.xml 74 75 data x_test.bweight; 76 set sashelp.bweight; 77 run; NOTE: SAS-Variablenetiketten, Einleseformate und Längen werden nicht in DBMS-Tabellen geschrieben. NOTE: There were 50000 observations read from the data set SASHELP.BWEIGHT. NOTE: The data set X_TEST.BWEIGHT has 50000 observations and 10 variables. NOTE: Verwendet wurde: DATA statement - (Gesamtverarbeitungszeit): real time 16.46 seconds cpu time 16.31 seconds 78 79 proc freq data=sashelp.bweight; 80 tables married; 81 run; NOTE: There were 50000 observations read from the data set SASHELP.BWEIGHT. NOTE: Verwendet wurde: PROZEDUR FREQ - (Gesamtverarbeitungszeit): real time 0.06 seconds cpu time 0.05 seconds 82 83 proc freq data=x_test.bweight; 84 tables married; 85 run; NOTE: There were 50000 observations read from the data set X_TEST.BWEIGHT. NOTE: Verwendet wurde: PROZEDUR FREQ - (Gesamtverarbeitungszeit): real time 6.10 seconds cpu time 5.89 seconds 86 87 libname x_test clear; NOTE: Libref X_TEST has been deassigned. So you have a time factor of 100(!) with a very small dataset that is just 4MB (BASE) on disk. As XML, it grows by a factor of about 4 to 15 MB.   ... View more

I suggest SAS Tech Support is the best place to progress your question, then post their response back here as I'm sure a lot of users would be interested. ... View more

Thanks for the like, @ChrisNZ . Here are the details on what is migrated: Concepts: MIGRATE Procedure . For data sets,  PROC MIGRATE retains alternate collating sequence, compression, created and modified datetimes, deleted observations, encryption, extended attributes, indexes, integrity constraints, and passwords. See the link for more details.   There is a tricky scenario that tends to affect customers with DBCS data - If you are changing to a different character encoding that uses more bytes to represent the characters, you might need to use the CVP engine as part of the copy or migration process, to avoid truncation. This works fine with PROC COPY, but CVP is not currently supported by PROC MIGRATE. We like PROC MIGRATE better than PROC COPY for migration, so we came up with a workaround. It's a little complicated but we recommend a two-step process where you (1) COPY with the CVP engine on the source environment to avoid CEDA. Then (2) MIGRATE on the target to change the encoding and data representation. If the library has formats catalogs, you can use a two step process with PROC FORMAT to expand the length and avoid truncation. ... View more

Hi, Based on below table: Description Primary_Account_No No_apps A1_DOB A2_DOB A3_DOB A4_DOB A1_Exist_customer A2_Exist_customer A3_Exist_customer Actual_value 12345678 3 19350119 19650420 19600507 0       Expected_value 12345678 3 19350119 19650420 19600507 0 M M M STATUS 12345678 PASSED PASSED PASSED PASSED PASSED FAILED FAILED FAILED Actual_value 12345679 3 19440223 19710705 19700720 0       Expected_value 12345679 3 19440223 19710705 19700720 0 M M M STATUS 12345679 PASSED PASSED PASSED PASSED PASSED FAILED FAILED FAILED Actual_value 12345680 2 19670201 19701019 0 0       Expected_value 12345680 2 19670201 19701019 0 0 A A   STATUS 12345680 PASSED PASSED PASSED PASSED PASSED FAILED FAILED PASSED   can i output something like this: Variable Passed Failed Total Primary_Account_No 73 27 100 No_apps 27 73 100 ... View more

Please describe what you are doing that "trailing blanks" is causing problems or affecting your analysis. ... View more