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/80838f1ca795b14ea1af48659f35166f1ce...@drexch02.corp.globetax.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.
