Dear SAS Experts, I am currently working on merging two datasets, dataset1 and dataset1, using a common column x. However, I’m facing challenges due to inconsistencies in the format and length of the values in this column across the two datasets. Below are the different scenarios I’ve encountered: The x column in dataset1 contains missing values, whereas the corresponding values are present in x column in dataset2. The x column in dataset1 contains 3-digit values (some starting with zero), but the same values appear as single or double digits in x column in dataset2. In some cases, x column in dataset1 has 3 or 5 digits, while in dataset2 the corresponding value appears as a shorter form. For these, I need to match based on the last 2 digits. In other cases, x column in dataset1 has 3 digits, while in x column in dataset2 the corresponding value appears as a 5-digit code. For these, I need to match based on the  last 3 digits. When x column has 5 digits in both datasets, the records should match exactly. If x column in dataset1 has 5 digits and in x column in dataset2 has 14 digits, I need to match based on the last 5 digits. Could you please suggest an efficient and reliable approach to standardize or transform these values and perform a successful merge that accommodates these scenarios? Thank you in advance for your support. ... View more

Hi everyone, I’m accessing Snowflake tables through SAS Data Integration Studio using the Snowflake connector. When I register  table from Snowflake in SAS DI, I noticed that VARCHAR(n) columns are automatically assigned LENGTH=3n in SAS metadata. For example: VARCHAR(2) becomes LENGTH=6. Why does this happen, even though both systems use UTF-8? Thanks in advance! ... View more

Git doesn’t need to be hard to understand and use, and in this post, I want to walk you through a practical way of using Git with SAS Studio in SAS Viya. SAS Studio provides a nice user interface to Git that makes working with Git much easier to use than using Git from the command line. No complex syntax to understand, no details to remember – you can simply point and click on what Git commands you want to use. And the information Git needs will be there for you - so no need to type in extra details.   See the screenshot below for a sample view of the Git user interface inside SAS Studio in SAS Viya:     Figure 1: Screenshot of SAS Studio Git user interface   My previous blog - Demystifying Git: A Survey of Data and AI Users on SAS - SAS Support Communities indicates that 59% from our local user community already use Git on at least a weekly basis for their data and AI work. The survey also tells us that 41% use Git less often – which tells us there is a potential to get more users to enjoy the benefits of using Git.   As you can find from this blog - Why Use Git for Data and AI Work in SAS Studio? - SAS Support Communities, there are good reasons to use a version control system like Git to save the day when you accidentally mess up your colleague’s work. Git will help you move back in time before the accident happen and get you back to a state when everything looked good.   In this post I will show you how to use SAS Studio with GitHub – one of the most popular hosted version control systems. SAS Studio also works well with Gitlab, Azure Repos and Bitbucket and quite a few others. And they will work quite similarly to how GitHub works with SAS Studio. Most of these version control systems can also be hosted by your own organization on-prem in case the hosted options are not available.   Prerequisites To be able to connect SAS Studio with GitHub, there are a few prerequisites that needs to be in place: A managed version control system – GitHub for instance, other systems work also, like GitLab, BitBucket, Azure Devops and quite a few others. Most of these also provides on-prem installations if there is a need to set these up inside your own network. SAS Studio enabled for Git integration – and integration through HTTPS if you want to connect through HTTPS, SSH Git integration if you want to connect through SSH An available authDomain where you can store a personal access token to authorize access to Git on your behalf – this was a change in SAS Viya from the 2024.12 release – see Prepare for Git Authentication Changes in SAS Studio on SAS Viya. If you don’t have any or don’t find any, ask your SAS Administrator to create one for you. Your personal Home folder on a file system mounted to SAS Studio. Although possible to use a commonly available file system, Git will be less able to properly track your changes when using a commonly shared folder.   Connecting through SSH or through HTTPS with Personal Access Token There are essentially 2 ways of connecting to GitHub from SAS Studio – through SSH or through HTTPS. What to use typically depends on policies in your organization – some may prefer SSH, and some may prefer HTTPS:   Using SSH involves a process of creating private and public keys and making those keys available to SAS Studio. Using HTTPS involves a process of creating a Personal Access Token in GitHub and making that token available to SAS Studio.   Although similar, I find HTTPS using a Personal Access Token more user friendly.   An overview of the process of how to connect SAS Studio with GitHub through HTTPS using a personal access can be illustrated as follows: Figure 2: Overview of connecting SAS Studio with GitHub   Generate Personal Access Token (PAT) in Github Enter SAS Environment Manager and store this PAT in My Credentials in an available authDomain Enter SAS Studio and Define a Git profile with HTTPS based on this authDomain (that holds the PAT) – use the userid and email that you have on your GitHub profile In SAS Studio, clone a git repository from GitHub based on this Git Profile Now you can work as usual in SAS Studio on the files you have access to in this cloned Git Repository. As this is cloned – you are now working on the local Git repository. Through the Git user interface in SAS Studio, you can stage the changed files if you are ready to commit these changes to your local repository. Commit with a meaningful commit message when are ready to do so. To get these committed changes back to GitHub, you need to Push the changes – and the Git user interface in SAS Studio helps you do that.   We will go through each of these in more detail, as there are some important details to be aware of. As the Personal Access Token is literally the key to your GitHub, care needs to be made both in GitHub when creating the token and when saving the token in SAS Viya.   For those interested in connecting to GitHub using SSH – there will be a separate blog about that approach.   So let us go through each of the steps above in more detail.   First let us log in to GitHub and create our Personal Access Token (PAT).   1. First time Git connection – creating the Personal Access Token in GitHub   Figure 3: Details on creating a Personal Access Token from GitHub   The following explains each point from the illustration:   Enter profile by clicking on your user image on the upper right corner Enter Settings Enter Developer settings in the menu that comes up Enter Personal access tokens (classic) Choose generate new token (classic) Specify name, expiration (duration) and repo scope – nothing else Hit generate new token at bottom of page Copy token Configure SSO if you need to authorize access to your organization’s repositories Hit the “Authorize” button to finalize authorizing access to the organization you want to authorize SSO into Now that we have our Personal Access Token, we can store it in My Credentials inside SAS Viya Environment Manager.   2. Saving the Personal Access Token in Environment Manager Figure 4: Details on storing the Personal Access Token from GitHub in My Credentials inside SAS Viya Environment Manager     The following explains each point from the illustration:   Enter My Credentials in Environment Manager Hit new credentials (asterisk) Pick an authDomain that is available – ask your SAS admin if you are unsure which to use or if you don’t find any, DO NOT use defaultAuth – it is used internally in SAS Viya Enter a userId for this credential. Use your full name - this is case sensitive, so type it in exactly as you want it – you might as well use the one you have in GitHub. When setting up the Git Profile in SAS Studio on the next page – SAS Studio will match against this UserId. Enter the personal access token (PAT) you created in GitHub as the password. We can now use our Personal Access Token by referencing this AuthDomain when defining the Git Profile in SAS Studio.   3. Define Git Profile in SAS Studio Figure 5: Details on defining a Git Profile in SAS Studio   The following explains each point from the illustration:   Under options menu, choose Manage Git Connections In the manage Git Connections window, choose Profiles Hit ‘+’ to add a git profile In the add profile window, choose the https option Give the profile a meaningful name – for instance My GitHub As the commit author name, enter the userId you stored in My Credentials (previous page)– exactly as written, this is case sensitive and will be matched against the entry with that userId As the commit author email, enter the email from your GitHub profile Select the authDomain where you stored the GitHub Personal Access Token (previous page) Hit ‘OK’ to save the new Git profile in SAS Studio Now that we have gotten ourselves a Git Profile in SAS Studio, we can use that Git Profile to clone Git repositories to our SAS Studio environment.   4.      Clone Git repository from GitHub Figure 6: Details on cloning a Git repository from GitHub to SAS Studio   The following explains each point from the illustration: In the ‘Manage Git Connections’ window, choose the Repositories page Hit the ‘+’ button to Clone a repository Enter GitHub in another browser tab, pick the repository you want to clone and hit the Code button (the green one) Select the HTTPS option Copy the link to the GitHub repository by hitting this button Paste the link to the GitHub repository you want to clone in this field In your home folder, create the folder you want to clone the repository to – you will not be able to clone into SAS Content as this is not a file system Name the folder for your local Git repository – the same name as the repository you are cloning from is a good practice - select the folder you created to get that back into the clone repository screen Select the Git profile you created in the previous page Hit ‘Clone’ and the GitHub repository will be cloned into the folder you specified   Now that we have cloned our repository from GitHub, we can work with the files and folders in that repository inside SAS Studio.   5.      Use Git from SAS Studio – develop and save work Figure 7: Details on how to develop and save work from a local Git repository in SAS Studio   The following explains each point from the illustration: The Git icon at the left of the folder indicates this is a Git managed folder in SAS Studio This button provides a list of Git repositories to work with inside SAS Studio You can now work in SAS Studio on files in this Git managed repository, save that work and Git will detect what files have changed This tab holds a user-friendly interface to work with Git – let us look at that in our next section.   5.4 Use Git in SAS Studio to stage and commit to our local repository Figure 8: Details on how to stage and commit changes to our local Git repository in SAS Studio   The following explains each point from the illustration: The user interface to Git in SAS Studio provides a list of files that Git has detected changes on locally inside SAS Studio This button performs a “stage” on all changed files – you can also stage files individually. Staging means we are telling Git that the changes to these files are ready to be committed to our local repository inside SAS Studio Once we are ready to commit these staged changes to our local repository – we can enter a meaningful commit message and hit the commit button.   Now that we have committed our changes to our local Git repository in SAS Studio, we can push those changes back to the remote repository in GitHub that we cloned it from.   6.      Push back to our remote repository in GitHub Figure 9: Details on how to push committed changes from our local Git Repository back to GitHub   The following explains each point from the illustration: As these changes are only committed to our local repository inside SAS Studio, we need to hit the push button to push these changes back to the repository we cloned it from. Notice the commit message now being visible in our remote GitHub repository which shows that these changes are now available in the remote GitHub repository as well   Summary – what we just did After all this detailed work, it makes sense to reflect on what we did – so let us review the illustration we started with: Figure 10: Overview of connecting SAS Studio with GitHub   First we generated our Personal Access Token (PAT) in GitHub. Then we stored this PAT in My Credentials in an available authDomain using SAS Viya Environment Manager. Then we defined a Git profile in SAS Studio with HTTPS based on this authDomain (that holds the PAT) – and we used the userid and email that we have on our GitHub profile Then we cloned a Git repository from GitHub based on this Git Profile in SAS Studio At this point, we are ready to work as usual in SAS Studio on the files we have access to in this cloned Git Repository. As this is cloned – we are now working on the local Git repository. Through the Git user interface in SAS Studio, we can stage the changed files when we are ready to commit these changes to our local repository. Commit with a meaningful commit message when ready to do so. To get these committed changes back to GitHub, we need to Push the changes – and the Git user interface in SAS Studio helps you do that.   So, with that – are you ready to use Git efficiently with SAS Studio in SAS Viya?   Questions and other feedback are welcome in the comments.   References used in this post: Demystifying Git: A Survey of Data and AI Users on SAS - SAS Support Communities Why Use Git for Data and AI Work in SAS Studio? - SAS Support Communities Prepare for Git Authentication Changes in SAS Studio on SAS Viya   ... View more

Model versioning is a critical capability for many of our users. Versioning allows users to make alterations to a model over time while tracking those changes. Additionally, those with robust needs for model governance have built model validation processes centered on a model version. These users had previously asked to use any version of a model in a decision flow, score test, performance monitoring report, and deployment. All of this was available by the 2024.01 release of SAS Viya.   The next request we took on was to make version bumping, when publishing or setting a champion role, optional. With the release of SAS Viya 2025.05, you can decide whether to create a new model version for these two actions. But, with this option, the use of model version locks is expanded to prevent editing published or champion model versions.   Up until this point, you could publish the latest version of a model and see that the model version went through a major version increase automatically. Or you could set a model as champion and see an automatic minor version increase. For example, you might publish version 2.0 of a model. This version would be published, and model version 3.0 would be created. Version 2.0 would be read-only, meaning that it could not be edited. This mechanism enforced an audit history for published models. Model version 2.0 in SAS Model Manager would exactly match what was published. So, if you ever wanted to see what was published in each destination, you would only need to check what was in SAS Model Manager.   Setting a model champion had a similar process. You might set a model version 1.2 as champion and see that model version 1.3 was created. Version 1.2 would be read-only, again to preserve a version history. But why is a version history of the champion important? Well, there are solutions that pull models from SAS Model Manager when they are set as champion.   All of that to say: we still need to prevent editing of any model version that is published or set as champion to preserve an audit history of model versions existing in our environments and tools. Hence, edit locking. Historically, previous (i.e., non-latest) model versions have been read-only and locked from editing. Now users can lock the latest version of a model from editing if they opt not to create a new model version when publishing or setting the champion role. When they are ready to edit the model, they can create a new major or minor version in a few clicks.     When publishing a model, users will now have a checkbox to create a new version after publishing or not. If they opt to not to create a new version, the latest version will be read-only. If users want to make edits, they need to manually create a new version. Similarly, when a user sets a model as champion, there will be a checkbox to create a new version or not. And again, if they choose not to create a new version, the latest version will be read-only, but they can create a new version when they are ready to make edits. Users who always want to create a new model version when publishing or setting the champion role can leave this box checked and can continue working as they are today. But this provides others teams the ability to control when a new model version is created.  See the following demo to learn more:     What feature would you like to see next in SAS Model Manager? Let us know in the comments! ... View more

Hi everyone, I’m accessing Snowflake tables through SAS Data Integration Studio using the Snowflake connector. When I register  table from Snowflake in SAS DI, I noticed that VARCHAR(n) columns are automatically assigned LENGTH=3n in SAS metadata. For example: VARCHAR(2) becomes LENGTH=6. Why does this happen, even though both systems use UTF-8? Thanks in advance! ... View more