Re: Deploy .NET driver Winform app problems
Posted in 2007
Topics: Installation, Setup & Upgrades, Connectivity: ODBC / JDBC / .NET, Security, Permissions & Auditing, Networking & sqlhosts Configuration
You should have setnet32 entries that you can model from on the machine you're developing on, or any machine where your application works for that matter. You need: 1) The servername or IP of the Informix server 2) The port number IDS is listening on 3) The protocol used to connect to the server, usually onsoctcp. 3) A username and password Unless the 3.0 CSDK remove the need for setnet32 entries, which I bet it does not, you will have to add the entries to setnet32, sorry. Setnet32 entries are stored in the registry so you could script the addition of the entries that you need just don't ask me how, I'm not a registry guy. I doubt that the 3.0 driver will make your deployment any easier but I have not "played" with the 3.0 CSDK yet so I really cannot speak to that. I would think that your only chance at the 3.0 CSDK making your life easier is if the current .NET provider is replaced with a native one, which I had heard would be happening, and the new provider does not require setnet32, doubtful but desirable. DL ----- Original Message ---- From: "srussell705@gmail.com" <srussell705@gmail.com> To: informix-list@iiug.org Sent: Thursday, July 5, 2007 3:36:39 PM Subject: Re: Deploy .NET driver Winform app problems On Jul 5, 2:57 pm, DL Redden <redde...@yahoo.com> wrote: > To my knowledge the 2.90 Informix .NET provider sits on top of the ODBC layer, i.e. when you open a .NET database connection a dynamic ODBC connection is created. You don't need to create an ODBC connection on the file server but you do need to have the Informix CSDK or CONNECT installed on it. The reason is that the .NET DLL uses libraries that are supplied by the CSDK or CONNECT install. You will also need to configure the database server that your trying to connect to in setnet32. (I'm pretty sure this is your problem). > > DL Thanks for the reply. Is the 3.x driver better from an easier deploymnet perspective? If so I'll get it and reinstall an SDK. >From your reply I see lots of hands on work for my sysAdmins, and that won't go over very well. Current users have the 2.5 SDK. I realize that everyone needed an upgrade for the .NET driver :( After that SDK install do we have to create a configuration in the Setnet32.exe? And if so what do I define? I was planning on using a pure DSN-Less environment for these one off business apps that only need 2-3 users. Client wants multiple apps over next month or two. __Stephen _______________________________________________ Informix-list mailing list Informix-list@iiug.org http://www.iiug.org/mailman/listinfo/informix-list
On Jul 5, 4:15 pm, DL Redden <redde...@yahoo.com> wrote: > You should have setnet32 entries that you can model from on the machine you're developing on, or any machine where your application works for that matter. You need: > > 1) The servername or IP of the Informix server > 2) The port number IDS is listening on > 3) The protocol used to connect to the server, usually onsoctcp. > 3) A username and password > > Unless the 3.0 CSDK remove the need for setnet32 entries, which I bet it does not, you will have to add the entries to setnet32, sorry. Setnet32 entries are stored in the registry so you could script the addition of the entries that you need just don't ask me how, I'm not a registry guy. > > I doubt that the 3.0 driver will make your deployment any easier but I have not "played" with the 3.0 CSDK yet so I really cannot speak to that. I would think that your only chance at the 3.0 CSDK making your life easier is if the current .NET provider is replaced with a native one, which I had heard would be happening, and the new provider does not require setnet32, doubtful but desirable. Thanks for the registry pointer. I'll see what I can find in my registry, then in my app load write it first and see if that works. I am disapointed with the driver if I have to plug the registry each time I make a UserID/PW change. Corporate rules are to change them monthly in data connections for some apps, and guess which ones I have to control? I'm not afraid to write to the reg or update the sucker. It's just a sorry kludge when I have a connection string defined in the app.config and I want it encrypted and easily updated.
On Jul 5, 4:50 pm, srussell...@gmail.com wrote: > On Jul 5, 4:15 pm, DL Redden <redde...@yahoo.com> wrote: > > > You should have setnet32 entries that you can model from on the machine you're developing on, or any machine where your application works for that matter. You need: > > > 1) The servername or IP of the Informix server > > 2) The port number IDS is listening on > > 3) The protocol used to connect to the server, usually onsoctcp. > > 3) A username and password > > > Unless the 3.0 CSDK remove the need for setnet32 entries, which I bet it does not, you will have to add the entries to setnet32, sorry. Setnet32 entries are stored in the registry so you could script the addition of the entries that you need just don't ask me how, I'm not a registry guy. > > > I doubt that the 3.0 driver will make your deployment any easier but I have not "played" with the 3.0 CSDK yet so I really cannot speak to that. I would think that your only chance at the 3.0 CSDK making your life easier is if the current .NET provider is replaced with a native one, which I had heard would be happening, and the new provider does not require setnet32, doubtful but desirable. > > Thanks for the registry pointer. I'll see what I can find in my > registry, then in my app load write it first and see if that works. > > I am disapointed with the driver if I have to plug the registry each > time I make a UserID/PW change. > > Corporate rules are to change them monthly in data connections for > some apps, and guess which ones I have to control? > > I'm not afraid to write to the reg or update the sucker. It's just a > sorry kludge when I have a connection string defined in the app.config > and I want it encrypted and easily updated. the registry looks like a hack for the PW so I'll avoid that!!!