Hi, Have one version of the Teradata Client installed on the laptop where I do my compiles. I want to use another version of the Teradata.Client.Provider for my compiles. Can I just point to the right disk files and use another Teradata.Client.Provider version other than the Teradata Client that is installed on my machine? I know this works for the compile. When I point at the older Teradata.Client.Provider all my Teradata calls resolve and my compile is successful. But when I run it I get a Teradata.Net.Security.Tdgss file not found. So how many disk files would you have to provide to get it to use an older version of Teradata.Client.Provider and would you have to specify any app.config configuration setting xml?
One of my associates asked this question directly of Teradata support. This is what they said: "TERADATA DO NOT (SIC) SUPPORT THE REVERSE SCENARIO; I.E. AN APPLICATION BUILT WITH A LATER VERSION (E.G.15.11) OF THE DATA PROVIDER TO WORK WITH AN EARLIER VERSION OF THE DATA PROVIDER(E.G. 15.0)." So, moving forward, Teradata is demanding absolute lock step between the client install and the server install of the Teradata Client, even for a dot release (I could see it on a full 14.x to 15.x release). A little bit of a problem for a large organization that may have several back end teradata servers and 100's of teradata client users, many with different use scenarios. Like some teradata client users are only interested SQL Assistant and others, like me are using it to compiles. So my large organization just forced me to do a client upgrade on my compile laptop and my back end admin guys/gals are telling me they don't want to be rushed in to changing the teradata clients on the server. So something to consider if you are buying database products.
When I use Oracle or MS Sql I never even think about this. MS Sql I won't hold against Teradata, they control the compiler.
1- You can install two or more version of the .NET Data Provider for Teradata on you workstation. This concept is called Side-By-Side and the .NET Data Provider for Teradata has supported this feature from the very beginning (version 1.1).
2- You can setup your project to build with any version of the .NET Data Provider for Teradata assuming you have two or more versions installed on your workstations.
3- The .NET Data Provider for Teradata ships with Publisher Policy files. The Publisher Policy files will re-direct CLR to the newer versions of the .NET Data Provider for Teradata. This means that existing applications build with an earlier version do not need to recompile to run with a newer version.
4- It is true that we will not support building with a later version (e.g. 20.0) of the .NET Data Provider for Teradata but running with an earlier version (e.g. 15.0).
5- The Teradata.Client.Provider.dll assembly loads the Teradata.NEt.Security.Tdgss assembly. the Teradata.Net.Securityf.tdgss.dll is in the PrivateAssemblies directory (e.g. C:\Program Files (x86)\Teradata\NET Data Provider for Teradata\15.0\PrivateAssemblies).
NetFx, Thanks this is helpful. I know the .Net Data Provider for Teradata folder and have used it a lot. Hopefully the directory is all I need to get it to compile and run (I don't particularly want to uninstall Client 15.11 and re-install 15.0).
I would mark the NetFx post as "Solve" but I don't see where to do this. I was able to solve this problem and I want to go over it because it might help others.
So there are three version of teradata we need to concern ourselves with here: the teradata server itself, the teradata client that is on dev/prod servers that access teradata from mostly batch jobs, and the teradata client on a desktop or laptop. The Teradata Server is pretty forgiving. I found that it would accept all prior versions (that we were trying to give it) and I even think that a lower version of the Teradata Server accepted at a to release level a higher level desktop trying to connect to it. It is the desktop/laptop versions of teradata that have to be in sync. In my case my big company forced me to upgrade to a higher teradata version for my laptop and because of what NetFx says above on #3, I could then not get my executables to run on my servers because my compile was now higher than the server teradata client. Most developers chose when to upgrade their teradata client and shouldn't have this problem.
So big companies, taketh away but they also give. Turns out all software installs at my company cache themselves. I found my old .Net Provider for Teradata (and I found it had to be exectly the one, even like 15.00 and 15.05 wouldn't work together), pointed to that in my c# Reference command, and my server executions started working again without upgrading the server execution client. I also found that you have to have the whole .Net Provider for Teradata, you can't just point at teradata.client.provider.dll and have it work.
In another thread other than this one NetFx suggests looking a Specific Version. If you do have a chance that your Client could upgrade when you don't want your compile to change I think I found a way to use Specific Version to allow me to control when I want upgrade the teradata client on my compiler machine. After I got my compile working with my server machine I set Specific Version to True from its' default false. I'm trying to upload what that looks like in Visual Studio but I don't know if it's going to make it. I personally think Teradata made a mistake here. I don't think you should ever change anything important in a developers compile without them specifically asking for that. A dot.net Console/Web project in Visual Studio saves all the important References with a compile and we have TFS. For my teradata client to change in my compile just because I upgraded the teradata client on my laptop (maybe I just wanted the new SQL Assistant) was really surprising.