Archived from groups: alt.internet.wireless (
More info?)
David,
Tim's response makes sense to me, I just wanted to say that the OLE DB thing
was something I picked up from the Internet and not something I have
experience with myself
General recommended approach would thus be:
1) Establish that it is indeed the wireless link causing the problems (and
not e.g. some wrong MTU or other setting in their environment)
2) Determine the conditions under which it occurs in general (e.g. >0.5%
packet loss or link drops)
3) Either make the application more robust against this and/or declare
limits of what you're willing to support
To me 3-4 times a day of a dropping wireless link (that's what it sounds
like, assumption) does not sound extremely unstable as a network, it should
be possible to tweak some settings (probably timing related) to get more
robustness (like you were already trying to do)
Good luck,
Jeroen
"Tim" <Tim@NoSpam.com> wrote in message news:ce2l8t$nte$1@lust.ihug.co.nz...
> David,
>
> Test by all means, but I doubt very much that OLE DB will do anything
> different. After all under the hood many implementations of OLE DB use
> ODBC - I am forgetting that you are using Sybase, but I expect it will be
> much the same as MS SQL Server (due to their shared heritage).
>
> Your observation that the link hangs if you increase some timeout
> indicates to me that it is a network connection problem. There are two
> timeouts for ODBC: Login and Query - their use and difference is quite
> obvious. If you set query timeout to 0 = infinite then the client end will
> wait forever for queries to finish. If this happens intermittently and
> runnning the Sybase equivalent to SQL Server Profiler shows that the
> queries themselves are not intermittent then you have some evidence that
> it is the link itself. Some ping testing running at the same time would
> hammer home that it is the link.
>
> If you have a link that is so intermittent (if) then there is little you
> can do from an application coding perspective other than reducing the
> number of interactions with the server, not using cursors (IE using
> firewall cursors instead, using stored procedures for 'actions' and so
> on). If you think about the more modern techniques for such situations
> where the client runs largely disconnected, then again, when they connect
> the same issues will occur and the system will still be hosed. So even
> though there is some merit in re-coding using a Web Service or
> Disconnected Application .Net style architecture as mentioned, it will not
> solve the problem.
>
> From an application coding perspective you can improve things by using
> stored procedures, firehose cursors to fetch data, not using server side
> cursors, generally architecting for maximum performance. There are many
> techniques that became normal (for me at least) in using ODBC & SQL Server
> that were obscure / poorly documented / not highlighted in programming
> literature that are now normal in .Net - IE those things I have just
> referred to. They all amount to doing everything with least impact on the
> server and network, and often having to do some extra coding to cater for
> such as using arrays to hold records retrieved by firehose cursors keeping
> in mind always the need for up to date data (EG stock or account balances,
> pricing etc) record locking, and so on.
>
> My recommendation would be to solve the lack of reliability in the
> wireless connections first and establish / publish reliability levels
> which your business requires to be attained before your system will be
> supported in such an environment. If a wireless network does not meet
> those standards of reliability (EG a 24 hour ping test with all responses
> within x% of norm) then your justification is simple: "There is no point
> in having a Network unless it works properly". Sounds a little harsh, but
> you could spend weeks on this and end up fixing their networking issues
> simply because they refuse to run a bit of cat5.
>
> Post back if you want to follow up on this.
>
> HTH
> - Tim
>
>
>
>
> "David Holstein" <dholstein@swiftdsl.com.au> wrote in message
> news:4104bc7c$0$27241$61ce578d@news.syd.swiftdsl.com.au...
>> Yes, what you are saying is right. It is a 'thick' client using ODBC. I
>> will
>> look at test scenario and also OLEDB.
>>
>>
>> Regards
>> David
>>
>> "Jeroen van Bemmel" <someone@somewhere.com> wrote in message
>> news:d29a7$41000243$513bab05$26274@news2.zonnet.nl...
>>> If I understand correctly your application consists of a server database
>>> with a 'thick' client that makes ODBC connections to it.
>>>
>>> My advice would be to get a wireless setup in your lab yourself and use
>> that
>>> for testing
>>>
>>> A simple test could be to see how your app handles an ethernet cable
>>> being
>>> unplugged, but that's not the same as the WLAN connection behavior
>>>
>>> A more robust solution would be to redesign your application to be less
>>> dependent on long-lived connections, but that's probably a lot of
>>> effort.
>>> Maybe tweaking of TCP settings could alleviate the problem a bit
>>>
>>> Also, I found several sources on the Internet stating that using OLEDB
>>> directly instead of ODBC could improve robustness and performance
>>>
>>>
>>> "David Holstein" <dholstein@swiftdsl.com.au> wrote in message
>>> news:40ffb4e2$0$27221$61ce578d@news.syd.swiftdsl.com.au...
>>> > Hi,
>>> >
>>> > Has anybody had any experience with database software on wireless
>>> > networks.
>>> > I have a customer who is saying that our application drops out 3 - 4
>> times
>>> > a
>>> > day. We use Sybase 7.0 which is a stable, robust database technology
>> which
>>> > runs on TCPIP. We have over 2500 pcs in our user base using wired
>> networks
>>> > who are having no networking problems (we would be out of business if
>> our
>>> > application was having problems with general networking).
>>> >
>>> > All customers who have tried wireless to date have stopped using it
>>> > due
>> to
>>> > various reasons. This particular customer is adamant that it is our
>>> > application and can't even accept that is MAY be the network. In ODBC
>>> > I
>>> > have
>>> > adjusted the "timeout" period in seconds from 5 seconds to 30 seconds
>>> > which
>>> > means that our app will not throw up a message until that time has
>>> > expired.
>>> > I did this about a week ago and he is now saying that the app now
>> freezes
>>> > and still drops out as well. The freezing to me is consistent with the
>>> > timeout period being increased.
>>> >
>>> > The wireless encryption is not enabled as our app drops out heaps
>>> > more.
>>> > The
>>> > site has concrete walls and it is a Dental surgery so I can see the
>>> > potential for interference. The router is a Belkin and I am unsure of
>> the
>>> > standard. It is not recent, is he ha had is for about 1 year.
>>> >
>>> > Can anybody help with the following:
>>> > 1. General advise on this topic.
>>> > 2. Any website or other info.
>>> > 3. Links to info on how to optimize software so that is more
>>> > compatible
>>> > with
>>> > wireless.
>>> >
>>> > Thanks, any help much appreciated.
>>> >
>>> > Regards
>>> > David
>>> >
>>> >
>>>
>>>
>>
>>
>
>
Facebook
Twitter
Instagram