Stephen - I really DO Agree with you. What you describe IS the Proper way to handle failover.
And - FYI - to answer your one question - the Disaster Recovery Server is being Mirrored constantly. -K- -----Original Message----- From: ProfoxTech [mailto:[email protected]] On Behalf Of Stephen Russell Sent: Friday, July 24, 2015 2:27 PM To: [email protected] Subject: Re: Connecting to SQL via VFP w/Failover... On Fri, Jul 24, 2015 at 11:38 AM, Kurt Wendt <[email protected]> wrote: > 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. > ------------- This is an automatic situation for failover to your mirror. The API does this all, unless of course there really is no Replication. Scary to hear that you might instead have defined a warm backup for catching transaction logs and applying them. If that is the case I shudder if it ever happens. When I said db below I was thinking of server\db assocation. Having multiple DBs and accessing them is easy because you just pass in Select * from [DBName].dbo.TableName instead of Select * from TableName If they that db is on a different machine/instance you just set up a linked server and and that as well. select * from [Server\Instance].[DBName].dbo.TableName Just watch out for passing lists in the where class from one server\instance to the other. That will make things go real slow! *--*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. This sets off warning bells in my head. It is easy to say just do it but the implication that everything is consistent between servers up until the failover is the crux of point. I do not know how you were keeping the two in sync. *--*-*When you refer to "The API" which "feeds to the proper Server for you" - are you referring to a routine within the VFP APP? NOPE! Sql Server is an API that you can touch with proper creds presented in your connection string. That API defines everything. In a replication situation it knows about the two servers, live and backup(n). It routes you to the LIVE one all the time even if the objects are all on backup2 in Texas instead of the local server room. The user is rarely aware that the failover happened and stuff just rolls on. When it comes to bringing everything back up that is when backups may have to be restored and the sync is reset between, then the failover back to primary db server takes place. Point is You think you are hitting SERVER ABC but the failover is really hitting SERVER XYZ and nobody had to do anything along the way. Oh yeah a connection to SERVER ABC never existed against SERVER XYZ, thus if your VFP form with data tries to update the backend it will fail, which is the initial problem I referenced. Normally in C/S code we always get a connection, do our stuff and then terminate the conn. This way we never expect the same connection to be valid 3 seconds, 3 min or 3 hours later. I think this book will cover what is happening on the server side: http://it-ebooks.info/book/82/ > > 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.
