|
I built a 32-Bit Windows application, which connects to 3 different database servers (3 different companies under one roof). The clients and servers are on different subnets ( servers on 192.168.60.xxx and clients on 192.168.58.xxx ). The only way I've been able to consistently connect is by creating 3 different ODBC Datasources, with the 'main' database always connecting, as it runs on the standard port 2638, however, in order to connect to the other two, I've had to burn in the port # in the DSN. Unfortunately, every time we reboot our server, the ports change... So, I'm wondering if I can create a SINGLE ODBC data source, and to dynamically provide the host, server name, port, and database name at the time of connection... |
Does one instance of the application connects to all three databases in parallel, or can choose to which single one to connect at a time, and in the latter case, can it "shift" to another database lateron within the same run?
Just to better understand: Do those three database servers run on the same machine or on different machines? (Database servers on different machines should not change their ports, and for multiple database servers on the same machine you can certainly provide "stable" port numbers by using the PORT protocol option with dbsrvX -x... FWIW, you do not need ODBC DSNs at all, SQL Anywhere also allows for DSN-less connections. E.g. you could use a connection string like the following: "Driver=SQL Anywhere 17;Server=demo17;UID=dba;PWD=sql;DBN=demo" 1
Just to be clear, the connection string would include the HOST=computer-ip:port connection parameter. For example, "DSN=basedsn;HOST=YKFN123456.global.mycorp:2639;Server=YKFN123456_OData;...". If you do use a DSN, then placing it at the start like this sets defaults for whatever parameters you specify in the data source, which can then be overridden using explicit parameters that follow.
(27 Nov '20, 12:24)
JBSchueler
Replies hidden
To confuse matters, there is a HOST connection parameter (shown above) and HOST protocol option that is a sub-parameter of the LINKS connection parameter. The latter (LINKS) is often used intead of the HOST connection parameter to prevent horrible mistakes in large, complex networks involving many subnets and SQL Anywhere servers. It is used because you can specify the DOBROAD=NONE protocol option to stop SQL Anywhere from disregarding the specified IP address and port number if they don't work. Without DOBROAD=NONE, under certain circumstances, the connection can be made to an entirely different server. With DOBROAD=NONE, according to the Help, "Specifying DoBroadcast=NONE causes no UDP broadcasts to be used, and the database server address cache (located in the sasrv.ini file) is ignored. A TCP/IP connection is made directly with the HOST/PORT specified, and the database server name is verified. If you specify DoBroadcast=NONE, the HOST (IP) protocol option is required." IMO, the DOBROAD=NONE behavior is what I ALWAYS want. I.e., if I specify the wrong IP and/or port, I WANT THE CONNECTION TO FAIL, not connect to some random server in a stinking cache or one that responds to a broadcast. IMO, the introduction of the HOST connection parameter was a BIG MISTAKE.
(27 Nov '20, 16:02)
Breck Carter
I may be wrong BUT AFAIK the HOST protocol option is an important "hint" whereas the HOST connection parameter is mandatory... Are you sure the latter may be ignored? The one known drawback for me is that the HOST connection parameter enforces TCP/IP even for local connection that would otherwise use ShMem.
(27 Nov '20, 16:28)
Volker Barth
When the Help Portal stops throwing "500 Internal Server Error", check out this topic: Troubleshooting: How the Host connection parameter locates database servers. ...so many words, so little clarity. I'm not "sure" about anything, except that DOBROAD=NONE on the client side has solved many problems over the years.
(27 Nov '20, 16:55)
Breck Carter
According to that particular FAQ, the undocumented IgnoreCache=Yes connection parameter might do the same trick when using the HOST connection parameter. However, I still wonder why it should be difficult to find an IP address in a different subnet... (I do understand it's "difficult" when you do not specify an IP address/host name but let the network search for a machine with the fitting database server name...)
(30 Nov '20, 02:06)
Volker Barth
|
|
You probably cannot get this into a single ODBC data source, but you could go completely without an odbc data source if you use SQLDriverConnect with a connection string instead of using SQLConnect. Obviously you can dynamically create the connection string yourself. You'll have to do a bit research on the details of the connect string. For Anywhere specific options look at DocCommentXchange. In addition you'll have to add the driver which should be used, for example as "Driver=SQL Anywhere 17" (this is the driver name displayed in the ODBC administrator). 1
I don't think there's particular research necessary, I guess this is similar to the part of my answer...:)
(19 Jan '21, 12:55)
Volker Barth
Replies hidden
Comment Text Removed
Indeed most of the answer can be researched from the previous ansers and comments (though I miss the "Driver=" parameter which AFAIK is critical and not in Anywhere docs). But maybe the main goal of my answer was to be short. :-)
(20 Jan '21, 03:49)
tedfroehlich
Well, that's why I think my answer has already contained that sample :)
(20 Jan '21, 06:04)
Volker Barth
|
I just have to ask. Why 32-bit?
Is it uncommon/bad to create 32-bit applications nowadays? If so, well, I have to re-think... :) (Database servers are 64-bit, of course...)
I may be wrong, but I think you get better performance out of 64-bit code. Just wondering why the need to create 32-bit apps after all this time. Do folks still have customers/clients running on old 32-bit Intel hardware?
What folks have is masses of 32-bit software. Have a look in your C:\Program Files (x86) folder :)
I have 92 items in that folder, including Acronis, Adobe, BraveSoftware, Google (Chrome), Mozilla Firefox, WinSCP, WinZip.
...and only 58 in C:\Program Files.
I'm guessing that address space is the primary motivation for using 64-bits, except maybe for games which need everything :)
...oh, and bitcoin mining :)
And computing power. I have a compute intensive application that, with the same inputs, takes 521 seconds in the 32-bit version and 475 seconds in the 64-bit version.
I did a similar check as you did and found a 32-bit exe in "C:\Program Files (x86)" dating to 09/30/1998. I'm not holding out hope for an update. :-)
But as far as developing new software, I would have thought that no one these days was thinking "oh, I better create a 32-bit version because some one is out there is waiting to run it on their old XP system".
Well, even Windows 10 still is offered as 32-bit version, so a 64-bit application won't run there...
Personally I think unless an application will take advantage of a larger address space, 32-bit is still more compatible (and uses slightly less resources, but that's probably less relevant nowadays...).
The Task Manager Processes tab showed I am running several "(32 bit)" apps... Chrome, Firefox, ExpressVPN, Microsoft Excel, PCMatic. I was surprised by Chrome, so I jumped through the hoops required to get the 64-bit version. Tried to do the same for Firefox, but the hoops were flaming so I gave up :)
Google says "in general you may expect a 2-20% performance gain from mere recompilation of a program"... I'm not sure what "mere recompilation" means because when I created a 64-bit version of the tiny C dll used by Foxhound, it was a nightmare.
In other words, anyone faced with having to support legacy 32-bit environments might think twice before offering a 64-bit alternative... Murphy's Law says 2% is more likely than 20% :)
PS I think Chrome 64-bit is faster... but I also think my car runs better after I wash it :)
> old XP system
My old XP system was 64-bit, what was yours? :)
I think of XP as the point where 64-bit first starting appearing. Wasn't 64-bit support added after XP was released? I seem to remember purchasing a computer with a 64-bit processor and strange looks when I said I wanted the 64-bit version of the XP. It's getting foggy... but I still have a Dell laptop at home running 32-bit XP that I use to connect to a piano's MIDI interface. Just have to put up with those pesky Microsoft notifications that my OS is gonna explode.
You are relating to the x64 version (Windows XP Professional x64 Edition), right? The Itanium 64-bit version was released alongside 32-bit Windows XP.
Isn't this somewhat similar (*) to SQL Anywhere 9, whose original Windows 64-Bit version was Itanium-based (and therefore doomed to fail), and a x64 version was added via a later 9.0.2 EBF?
(*) Note meant to compare XP to any SQL Anywhere relase, of course :)
Aside: What was the OP's question, anyway? :)