Sure, it all makes sense. And we're all making assumptions about your environment and now it works. If you have a "real" database failover, then the magic should be happening outside your application. If it's more like the other situation you describe, then you have to come up with your own variation of resetting the connection. Having said that, if the DB fails over at just precisely the right point in time you may still end up with a situation where the primary doesn't give you a connection and the failover hasn't spun up and restored its state yet.
And the way to really test this is to have a staging environment that matches your production world and have IT guys manually failover the DB. If the application continues to work gracefully, job well done. :-) If not, then you at least have a shot at figuring out how to make it more bulletproof instead of just hoping... ;-) -- rk -----Original Message----- From: ProfoxTech [mailto:[email protected]] On Behalf Of Kurt Wendt Sent: Friday, July 24, 2015 12:59 PM To: [email protected] Subject: RE: Connecting to SQL via VFP w/Failover... Richard, Yes - I did understand from Stephen - that I can't just think about the Failover at Startup. That, in essence - something should be in place while the app is running - so that the failover can properly occur at ANY point in time. NOT just at startup. But, for my current situation - I'm just at this point trying to make sure that the failover can happen at startup. Let me put it this way. One of the other systems here - which I have worked on - they do it differently. There is simply a Different version of the EXE that must be run - should a Failover be required. So - that app does NOT even detect that the Prod server is down. Instead, someone must somehow Switch which version of the App is being run - the Regular one - or the Disaster Recovery version. And, yeah - its not a very sophisticated methodology. In the case of the App I am working on - code was in place to Switch over - but, it was NOT Running in a way that made the Systems guy happy. And, that's why the request was made to change how it works. So - In Essence - about the only REAL Change I am making to the System - is STOPPING the SQL Connection Error message window from being displayed - AND the SQL Server Login window - and instead having the program automatically switch over to the DR Server when it Fails to connect to the Production Server/Databases. Does that make more sense? -K- -----Original Message----- From: ProfoxTech [mailto:[email protected]] On Behalf Of Richard Kaye Sent: Friday, July 24, 2015 12:48 PM To: [email protected] Subject: RE: Connecting to SQL via VFP w/Failover... I think one of Stephen's points is that the failover should be handled by the database infrastructure and not the application. The fact that you can make a connection to the DR failover is not proof of the application continuing to work when the DB fails over. I don't know enough about this to speak with authority but if your application gets a connection handle to the DB at startup which persists through its lifetime, which many client server applications do, the question becomes what happens to that connection handle when the DB fails over. If persisting connections is part of the failover process then perhaps your application will continue to work without even knowing that it's now hitting the DR server. OTOH you might need to be trapping for an invalid handle and reestablishing that on the fly. In a true failover you should not have to change your server info. I think... :-) -- rk -----Original Message----- From: ProfoxTech [mailto:[email protected]] On Behalf Of Kurt Wendt Sent: Friday, July 24, 2015 12:38 PM To: [email protected] Subject: RE: Connecting to SQL via VFP w/Failover... Stephen, I can see that this SQL stuff gets you a bit heated up. I know you say that I should NOT be thinking about the Server. But - Understand - the Specific task I was given was to make sure that upon the Start-up of the App in question - that IT could intelligently switch between our regular Production server and the DR server (Disaster Recovery) - should the Production server be down. As such - that's what I am trying to concentrate on. I have a Rather Overwhelming amount of projects that I have to work on here. And, just recently - this particular system was dumped upon me to support - so that the other Developer could concentrate on developing a New version of the system using .Net - which will replace the current VFP version. And, this request having to do w/Disaster Recovery - was totally "out of the blue". To make matters worse - they are having some kind of Systems Audit on Mon. - and that's why I need to Rush to get some proper coding in place. Also - you mentioned " ONE database in this situation ". That's actually not true. The app I am working on has a specific Database which holds most of its Data. But, it also needs to access Another Database - that's specific to Another system here - since both systems are related. When you refer to "The API" which "feeds to the proper Server for you" - are you referring to a routine within the VFP APP? As for Switching Stuff - the request I was given was to make sure that upon startup - This App can switch over to the DR server. For right now - that is my ONLY task at this point in time - regarding this issue. And - yes, its SQL Server 2008. -----Original Message----- From: ProfoxTech [mailto:[email protected]] On Behalf Of Stephen Russell Sent: Friday, July 24, 2015 12:21 PM To: [email protected] Subject: Re: Connecting to SQL via VFP w/Failover... On Fri, Jul 24, 2015 at 10:57 AM, Kurt Wendt <[email protected]> wrote: > Alright - a final follow-up. > > OK - as previously mentioned - my systems guy said I should only > connect to a Database if it's in Principal mode and Not in Mirror mode. > > So, to test this out - I connected into the Albany server using MSSM > Studio. And, when I went to look at one of the Databases in particular > - I saw that it had the status of Mirror. Where as, in another session > of MSSM Studio - I logged into our NYC Server - and the same Database > had the mode of Pricipal. Sure, that's all well and good - and what I > expected. > > Then I tried connecting to the Albany Server - and to that particular > Database - using the same login credentials I used in MSSM Studio. > Upon running that SQLSTRINGCONNECT statement - it returned a value of > "-1" as the statement handle. > > ----------------------------- There is only ONE database in this situation. The API will direct all feeds to the proper Server for you. You NEVER just switch stuff like this and think YOU HAVE TO change. Hence why I said this is tricky. Before you accidently screw things up you need to research WTF is going on on the API side and stop thinking about the server(s). What version of SQL are you running, 2008 or more recent? This is a MAJOR issue and not an easy little fix BTW. > So - my assumption is that - even though the SQLSTRINGCONNECT could > connect to the Server, and could "See" the Database in question - it "knew" > to return back a value of "-1" since the Database was in Mirror mode - > and should thus NOT be used. > > Am I right? I suspect in this case - my assumption is correct. But, > figured I should just get verification from those folks more > knowledgeable in this area than myself (a kind of newbie for some of this SQL > stuff)... > > Thanks again, > -K- > ----------------- > > -- Stephen Russell Sr. Analyst Ring Container Technology Oakland TN 901.246-0159 cell --- StripMime Report -- processed MIME parts --- multipart/alternative text/plain (text body -- kept) text/html --- [excessive quoting removed by server] _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/bn4pr10mb0913809b27748313a64ee9a3d2...@bn4pr10mb0913.namprd10.prod.outlook.com ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
