Hello!   Thank you for very much for your reply Cynthia. And appologies for the late reply .. I have fallen ill in between, this is why. This thread has gone cold meanwhile but let me answer to your post to show appreciation for your contribution.   I have traced back the "culprit" enty, it is a "č" character (a cech c with an inverted accent circonflex).  Encoding option is set to latin1 on the system (so I cannot change that). The xls is formated/saved with encoding "windows latin1", changing that to utf-8 or anything different does not change the behaviour.   Using libname xslx does result in the same transcoding errors as before.   We have not managed to come up with a resoluton for this behaviour/warnings so we decided to alter the data source. Not nice but a quick way out. Nevertheless I was courious if someone had some idea I could have play with. Please let me know. 🙂   As Cynthia has suggested one actually needed to go through this step by step with the tech support. But as we have that workaround in place I won't waste their time. 🙂    Cheers to all contributers ... and a Happy New Year to you all! 🙂 --fja      ... View more

Hello Chris! Thank you for that pointer ... and the nice and well crafted presentation, of course. Alas, the procedure sketched out there seems only be valid vor csv files. Working with EG 8.2 and and xlsx file to import I do not get the options offered that you have mentioned in your video. Could it be, that this is just implemented for csv and not for xlsx data sources? --fja   ... View more

Hello Tom! Thank you for your reply. Yes, there is a tick option at the last step of the import wizard of EG 8.2. Alas its behaviour/the generated code is pretty much unimpressed by having it set. But thank you for pointing this out. --Fja   ... View more

@AhmedAl_Attar wrote: This is one of the attractive security feature of Citrix, and it can be one of the most restricting/limiting/frustrating feature for users!  Namely the latter. 😞   Thank you for your reply Ahmed ... I will chase up the admins then.    Cheers   ... View more

Thank you @ChrisHemedinger for your remarks. Not what I was hoping for, but this defenitely clarifys things.   @ChrisHemedinger wrote: The Git integration with EG relies on local Git working with local EG, and cannot be used with any SAS-session based files. In your case, "local" is your Citrix terminal, so Git can work only with files that are accessible from the Windows system -- local and perhaps mapped drives. That means there is now way around having the destination to be mapped as a local drive. I see.  ... View more

@AhmedAl_Attar wrote: [...] Open a Terminal window connected to the SAS Linux server. You can do this via any SSH client software, alternatively you can use the SSH command from the windows CMD window [...] This way it should be clear where the issue is, rather than getting mixed signals 🙂 [...] Hello Ahmed! Thank you very much for your reply. You are all correct. But most unfortunately I do not have any access to the  server but through EG. So my attempt to use the X command is the closest thing to the approach you suggested. I have reported the results above. Cheers ... View more

@Quentin wrote: [...]but the admins weren't interested in investing time to get the authentication working between our linux SAS box and the windows box with the git repo.  [...] Oh this sounds ever so familiar! 😐 Thank's for the reply! ... View more

@AhmedAl_Attar wrote: I have a feeling your System Admins would need to install git on your SAS server before you could SAS's git functions  (gitfn_*) Hi Ahmend! Thank you for replying ... git is installed and available under /usr/bin/git (a unix system). But this seems to be messy ... as pointed out in this posting below.  Hence the question if a dedicated OS version of git was needed to run git in SAS via the gitfn_* functions. Cheers     ... View more

@ Bart: Thank you for indicating how it works on your side ... I guess this should be the solution I am looking for iff the git setup was correct. (see my posting above) ... View more

Another piece of information: when using x command git clone  git clone https;//<MeName>:<MePwd>@<host>/<MeName>/<repo>.git on the sas host I get Cloning into '<repo>'... /usr/lib/git/git-remote-https: /opt/sas/sas94m7/SASHome/SASFoundation/9.4/sasexe/libcrypto.so.1.0.0: no version information available (required by /usr/lib64/libcurl.so.4) /usr/lib/git/git-remote-https: /opt/sas/sas94m7/SASHome/SASFoundation/9.4/sasexe/libssl.so.1.0.0: no version information available (required by /usr/lib64/libcurl.so.4) /usr/lib/git/git-remote-https: /opt/sas/sas94m7/SASHome/SASFoundation/9.4/sasexe/libcrypto.so.1.0.0: no version information available (required by /usr/lib64/libssh.so.4) /usr/lib/git/git-remote-https: /opt/sas/sas94m7/SASHome/SASFoundation/9.4/sasexe/libssl.so.1.0.0: no version information available (required by /usr/lib64/libldap-2.4.so.2) /usr/lib/git/git-remote-https: /opt/sas/sas94m7/SASHome/SASFoundation/9.4/sasexe/libcrypto.so.1.0.0: no version information available (required by /usr/lib64/libldap-2.4.so.2) fatal: unable to access 'https://<host>/<MeName>/<repo>.git/': Failed to connect to <host> port 443 after 7247 ms: Couldn't connect to server Funny/remarkable thing is: the unix git command (/usr/bin/git) draws the sas so-libs. This seems to indicate that the git setup is messy on the host. EG however lets me clone it to the local PC, so the credentials seem to work. ... View more