SQLAnywhere performance over a WAN

Hello SQLAnywhere Pro's !!!

I have a client that uses our application (PB60 App) against a 20MB
SQLAnywhere (5.5.04) database (they are a new client - normally the database
would be about 100 - 200 MB)  running on Windows NT.  Performance has been
great.  They just linked up to another office of theirs via a Fractional T1
line (384K pipe).  There will be 8 additional users that will access the
database remotely.  There are 10 people accessing the database locally.  The
NT Server is a Pentium 400 with 256MB Ram.

The WAN has been completed and they are starting to test our app (which
resides on the workstations remotely) connecting to the database through the
384K channel. The response time is AWFUL!!!  A SELECT statement that returns
7 rows with 15 columns takes over 30 seconds.  Locally it takes about 1
second.  This is with only one user connected to the database #/#/

Here is that strange part!  The phone company is monitoring the line and the
banwidth saturation has not been greater than 20%.  I don't get it. Why is
it Soooo slow??

Here is what I have tried thus far:
I have increased the packet size on both the SQLAnywhere Server and client
from the default of 512K to 1500k. This did not work.

I also tried setting the tcpip parameters {sendbuffersize and
receivebuffersize}.  I increased these from the default of 64k to 128k.

Changing these settings actually made things worse.

I have changed the Cache setting from 2MB to 4MB to 8MB.  NO difference.

The only protocal that they are running on the NT  Server is TCPIP ( no IPX)

I'm baffled.  I could see if the bandwith saturation were higher but it has
only hit 20%.

Any Ideas ???




0
Kevin
9/1/1998 7:44:33 PM
sybase.sqlanywhere.general 32637 articles. 4 followers. Follow

11 Replies
453 Views

Similar Articles

[PageSpeed] 52

I seem to recall that setting the PB BLOCK option to 1 will increase
your performance figures.  If this works, you can set it to different
values to try and get an optimal one.  I also recall that limiting
embedded SQL calls also helped (since PB has to make lots of ODBC calls
to describe results and such).
You could also try turning off prefetching for the WAN clients and see
if that helps.

Jason Hinsperger
Product Quality
Adaptive Server Anywhere


Kevin Wydra wrote:
> 
> Hello SQLAnywhere Pro's !!!
> 
> I have a client that uses our application (PB60 App) against a 20MB
> SQLAnywhere (5.5.04) database (they are a new client - normally the database
> would be about 100 - 200 MB)  running on Windows NT.  Performance has been
> great.  They just linked up to another office of theirs via a Fractional T1
> line (384K pipe).  There will be 8 additional users that will access the
> database remotely.  There are 10 people accessing the database locally.  The
> NT Server is a Pentium 400 with 256MB Ram.
> 
> The WAN has been completed and they are starting to test our app (which
> resides on the workstations remotely) connecting to the database through the
> 384K channel. The response time is AWFUL!!!  A SELECT statement that returns
> 7 rows with 15 columns takes over 30 seconds.  Locally it takes about 1
> second.  This is with only one user connected to the database #/#/
> 
> Here is that strange part!  The phone company is monitoring the line and the
> banwidth saturation has not been greater than 20%.  I don't get it. Why is
> it Soooo slow??
> 
> Here is what I have tried thus far:
> I have increased the packet size on both the SQLAnywhere Server and client
> from the default of 512K to 1500k. This did not work.
> 
> I also tried setting the tcpip parameters {sendbuffersize and
> receivebuffersize}.  I increased these from the default of 64k to 128k.
> 
> Changing these settings actually made things worse.
> 
> I have changed the Cache setting from 2MB to 4MB to 8MB.  NO difference.
> 
> The only protocal that they are running on the NT  Server is TCPIP ( no IPX)
> 
> I'm baffled.  I could see if the bandwith saturation were higher but it has
> only hit 20%.
> 
> Any Ideas ???
0
Jason
9/1/1998 9:23:14 PM
We researched this as well (efficient packet sizes), and determined that
1480 was optimal use of an IP packet for SQLA.

On the server and each of the DBCLIENT command strings, set the packet size
= 1480 with -p 1480.
This may not give you back all the performance you're looking for, but every
little bit helps.

Paul Horan
VCI
Springfield, MA

Kevin Wydra wrote in message ...
>Hello SQLAnywhere Pro's !!!
>
>I have a client that uses our application (PB60 App) against a 20MB
>SQLAnywhere (5.5.04) database (they are a new client - normally the
database
>would be about 100 - 200 MB)  running on Windows NT.  Performance has been
>great.  They just linked up to another office of theirs via a Fractional T1
>line (384K pipe).  There will be 8 additional users that will access the
>database remotely.  There are 10 people accessing the database locally.
The
>NT Server is a Pentium 400 with 256MB Ram.
>
>The WAN has been completed and they are starting to test our app (which
>resides on the workstations remotely) connecting to the database through
the
>384K channel. The response time is AWFUL!!!  A SELECT statement that
returns
>7 rows with 15 columns takes over 30 seconds.  Locally it takes about 1
>second.  This is with only one user connected to the database #/#/
>
>Here is that strange part!  The phone company is monitoring the line and
the
>banwidth saturation has not been greater than 20%.  I don't get it. Why is
>it Soooo slow??
>
>Here is what I have tried thus far:
>I have increased the packet size on both the SQLAnywhere Server and client
>from the default of 512K to 1500k. This did not work.
>
>I also tried setting the tcpip parameters {sendbuffersize and
>receivebuffersize}.  I increased these from the default of 64k to 128k.
>
>Changing these settings actually made things worse.
>
>I have changed the Cache setting from 2MB to 4MB to 8MB.  NO difference.
>
>The only protocal that they are running on the NT  Server is TCPIP ( no
IPX)
>
>I'm baffled.  I could see if the bandwith saturation were higher but it has
>only hit 20%.
>
>Any Ideas ???
>
>
>
>


0
Paul
9/2/1998 1:35:42 AM
The two things needed are setting BLOCK=1 on the end of the PB connect
string (this is an ODBC option that can be set from non PB apps) and using
the retry switch -ts on the command line of the requestor, -ts 300,3000 or
something like it. Then design carefully so you dont fetch too much data, as
suggested dont do much embedded fetching, use datawindows as much as
possible. Even so the amount of traffic from the client to the server can be
moe than you would expect.

What is prefetching and how do you turn it off?



0
Clive
9/2/1998 9:33:23 PM
When it comes to network performance for database applications, transmission
delays are just as important as bandwidth. These are dependant on the
network infrastructure. Switches, routers, gateways etc., in addition to the
current traffic on the network of course. Since you're running IP you could
use the ping utility to verify that your network provides sensible
end-to-end delays. Depending on the amount of traffic on your network, and
the physical distance between your sites, you should not be happy before
reaching delays below 10-15ms.

As an aside I can tell you about a benchmark we once did with Anywhere
5.5.04 and a relatively large business application for a partner. The
performance was much worse than expected, and we got only small improvements
when playing around with dbclient and dbsrv settings. The problem was
related to a special brand of PCMCIA network interface cards for laptops.
When they were configured for both modem and ethernet traffic, they gave
normal, although not excellent, throughput, but had lousy transmission
delays. Disabling the modem functionality on the card reduced the
transmission delays from 20-25ms to well below 10ms end-to-end. We increased
the performance of this business application by roughly 250% by flipping a
radio button in the interface card configuration program.

The bottom line is that the performance of networked database applications
are particularly sensitive to transmission delays, and these are often given
by entities much further down the protocol stack than dbclient.


- Tor Erlend F�gri


Kevin Wydra wrote in message ...
>Hello SQLAnywhere Pro's !!!
>
>I have a client that uses our application (PB60 App) against a 20MB
>SQLAnywhere (5.5.04) database (they are a new client - normally the
database
>would be about 100 - 200 MB)  running on Windows NT.  Performance has been
>great.  They just linked up to another office of theirs via a Fractional T1
>line (384K pipe).  There will be 8 additional users that will access the
>database remotely.  There are 10 people accessing the database locally.
The
>NT Server is a Pentium 400 with 256MB Ram.
>
>The WAN has been completed and they are starting to test our app (which
>resides on the workstations remotely) connecting to the database through
the
>384K channel. The response time is AWFUL!!!  A SELECT statement that
returns
>7 rows with 15 columns takes over 30 seconds.  Locally it takes about 1
>second.  This is with only one user connected to the database #/#/
>
>Here is that strange part!  The phone company is monitoring the line and
the
>banwidth saturation has not been greater than 20%.  I don't get it. Why is
>it Soooo slow??
>
>Here is what I have tried thus far:
>I have increased the packet size on both the SQLAnywhere Server and client
>from the default of 512K to 1500k. This did not work.
>
>I also tried setting the tcpip parameters {sendbuffersize and
>receivebuffersize}.  I increased these from the default of 64k to 128k.
>
>Changing these settings actually made things worse.
>
>I have changed the Cache setting from 2MB to 4MB to 8MB.  NO difference.
>
>The only protocal that they are running on the NT  Server is TCPIP ( no
IPX)
>
>I'm baffled.  I could see if the bandwith saturation were higher but it has
>only hit 20%.
>
>Any Ideas ???
>
>
>
>


0
Tor
9/3/1998 10:17:58 AM
Thanks for posting your experience.  That's good stuff!
-- 
Jim Egan [TeamPS]
Houston, TX

0
Jim
9/3/1998 1:21:01 PM
When you execute a query and fetch data, the server will send back as
many rows as will fit in a message to the client.  This is in
expectation that more fetches will be done and so as to make the network
communication as efficient as possible.
You can turn prefetching off on the client by starting with the -r
switch.  You can turn off prefetching for all clients on the server by
starting the server with the -r switch.

Jason Hinsperger
Product Quality
Adaptive Server Anywhere



Clive Collie wrote:
> 
> The two things needed are setting BLOCK=1 on the end of the PB connect
> string (this is an ODBC option that can be set from non PB apps) and using
> the retry switch -ts on the command line of the requestor, -ts 300,3000 or
> something like it. Then design carefully so you dont fetch too much data, as
> suggested dont do much embedded fetching, use datawindows as much as
> possible. Even so the amount of traffic from the client to the server can be
> moe than you would expect.
> 
> What is prefetching and how do you turn it off?
0
Jason
9/3/1998 2:25:54 PM
This is a multi-part message in MIME format.
--------------1644DE274AD011570772E72F
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit



Paul A. Horan wrote:

> We researched this as well (efficient packet sizes), and determined that
> 1480 was optimal use of an IP packet for SQLA.
>
> On the server and each of the DBCLIENT command strings, set the packet size
> = 1480 with -p 1480.
> This may not give you back all the performance you're looking for, but every
> little bit helps.
>
> Paul Horan
> VCI
> Springfield, MA
>
> Kevin Wydra wrote in message ...
> >Hello SQLAnywhere Pro's !!!
> >
> >I have a client that uses our application (PB60 App) against a 20MB
> >SQLAnywhere (5.5.04) database (they are a new client - normally the
> database
> >would be about 100 - 200 MB)  running on Windows NT.  Performance has been
> >great.  They just linked up to another office of theirs via a Fractional T1
> >line (384K pipe).  There will be 8 additional users that will access the
> >database remotely.  There are 10 people accessing the database locally.
> The
> >NT Server is a Pentium 400 with 256MB Ram.
> >
> >The WAN has been completed and they are starting to test our app (which
> >resides on the workstations remotely) connecting to the database through
> the
> >384K channel. The response time is AWFUL!!!  A SELECT statement that
> returns
> >7 rows with 15 columns takes over 30 seconds.  Locally it takes about 1
> >second.  This is with only one user connected to the database #/#/
> >
> >Here is that strange part!  The phone company is monitoring the line and
> the
> >banwidth saturation has not been greater than 20%.  I don't get it. Why is
> >it Soooo slow??
> >
> >Here is what I have tried thus far:
> >I have increased the packet size on both the SQLAnywhere Server and client
> >from the default of 512K to 1500k. This did not work.
> >
> >I also tried setting the tcpip parameters {sendbuffersize and
> >receivebuffersize}.  I increased these from the default of 64k to 128k.
> >
> >Changing these settings actually made things worse.
> >
> >I have changed the Cache setting from 2MB to 4MB to 8MB.  NO difference.
> >
> >The only protocal that they are running on the NT  Server is TCPIP ( no
> IPX)
> >
> >I'm baffled.  I could see if the bandwith saturation were higher but it has
> >only hit 20%.
> >
> >Any Ideas ???
> >
> >
> >
> >

  I also use the -tl switch and set it to a higher value on both the server and
client which reduces the amount of liveness packets being sent over the WAN.

Bernard Mikowski

--------------1644DE274AD011570772E72F
Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Bernard Mikowski
Content-Disposition: attachment; filename="vcard.vcf"

begin:          vcard
fn:             Bernard Mikowski
n:              Mikowski;Bernard
org:            MEDS
email;internet: BMikowski@mesgroup.com
title:          Programmer/Analyst
x-mozilla-cpt:  ;0
x-mozilla-html: FALSE
version:        2.1
end:            vcard


--------------1644DE274AD011570772E72F--

0
Bernard
9/3/1998 11:58:04 PM
In addition to all the good suggestions in this thread, you might try testing with ISQL.  This will
help determine whether the problem is related to ODBC (esp. ODBC blocking). 


Leo Tohill - Team Powersoft
-- Please post in newsgroup, not via email <
0
leotohill
9/7/1998 3:17:40 PM
I have learned much about performance over the last two weeks.  I even
opened an issue with Sybase to see if I could get the performance issue
resolved.  They went over all the same settings that have been discussed
within this message thread ( packet size, buffersize - send/receive, BLOCK
ODBC setting, etc).  Unfortunately none of  these settings made any
significant impact.  The latency from the PING command ranges from 20-25 ms
on all the workstations over the WAN.  One of the threads said that getting
that value down to between 10-15 would help.  Unfortunately I don't think
that that is going to be possible.  They appear to be using good hardware
(Ascend router, 3Com Nic's).

BUTTTTT !!!! Let there be LIGHT.  As a last possibility the guys at Sybase
told me to download the 6.0 Adaptive Server Anywhere product and see if
there was any difference.  THERE WAS A HUGE DIFFERENCE.  On an average size
select statement a workstation over the WAN is only about 1-2 seconds slower
than on one of the local workstations !!!!!    I could not believe it.  I
can't figure out what they are doing different in the communications BUT I
DONT CARE - IT WORKS.  Hopefully we won't get bitten by any bugs (being the
..0 revision without any maintenance patches yet.)

I want to thank everyone who posted messages about my problem.  I sure did
learn a bunch about WAN performance.  I hope that posting my results will
help somebody else  in their endevors.

Kevin  Wydra.
Custom MIcro Systems



Kevin Wydra wrote in message ...
>Hello SQLAnywhere Pro's !!!
>
>I have a client that uses our application (PB60 App) against a 20MB
>SQLAnywhere (5.5.04) database (they are a new client - normally the
database
>would be about 100 - 200 MB)  running on Windows NT.  Performance has been
>great.  They just linked up to another office of theirs via a Fractional T1
>line (384K pipe).  There will be 8 additional users that will access the
>database remotely.  There are 10 people accessing the database locally.
The
>NT Server is a Pentium 400 with 256MB Ram.
>
>The WAN has been completed and they are starting to test our app (which
>resides on the workstations remotely) connecting to the database through
the
>384K channel. The response time is AWFUL!!!  A SELECT statement that
returns
>7 rows with 15 columns takes over 30 seconds.  Locally it takes about 1
>second.  This is with only one user connected to the database #/#/
>
>Here is that strange part!  The phone company is monitoring the line and
the
>banwidth saturation has not been greater than 20%.  I don't get it. Why is
>it Soooo slow??
>
>Here is what I have tried thus far:
>I have increased the packet size on both the SQLAnywhere Server and client
>from the default of 512K to 1500k. This did not work.
>
>I also tried setting the tcpip parameters {sendbuffersize and
>receivebuffersize}.  I increased these from the default of 64k to 128k.
>
>Changing these settings actually made things worse.
>
>I have changed the Cache setting from 2MB to 4MB to 8MB.  NO difference.
>
>The only protocal that they are running on the NT  Server is TCPIP ( no
IPX)
>
>I'm baffled.  I could see if the bandwith saturation were higher but it has
>only hit 20%.
>
>Any Ideas ???
>
>
>
>


0
Kevin
9/11/1998 7:34:57 PM
I do remember something about how they had vastly improved performance in
one of the late 5.5 patches or 6.0. I think they changed the basic
handshaking between the client and server. Since SQL Anywhere uses UDP and a
WAN probably loses a lot of UDP packets, improvement to the handshaking
probably was the difference.

Glad it is working well for you.

Dave



Kevin Wydra wrote in message ...
>I have learned much about performance over the last two weeks.  I even
>opened an issue with Sybase to see if I could get the performance issue
>resolved.  They went over all the same settings that have been discussed
>within this message thread ( packet size, buffersize - send/receive, BLOCK
>ODBC setting, etc).  Unfortunately none of  these settings made any
>significant impact.  The latency from the PING command ranges from 20-25 ms
>on all the workstations over the WAN.  One of the threads said that getting
>that value down to between 10-15 would help.  Unfortunately I don't think
>that that is going to be possible.  They appear to be using good hardware
>(Ascend router, 3Com Nic's).
>
>BUTTTTT !!!! Let there be LIGHT.  As a last possibility the guys at Sybase
>told me to download the 6.0 Adaptive Server Anywhere product and see if
>there was any difference.  THERE WAS A HUGE DIFFERENCE.  On an average size
>select statement a workstation over the WAN is only about 1-2 seconds
slower
>than on one of the local workstations !!!!!    I could not believe it.  I
>can't figure out what they are doing different in the communications BUT I
>DONT CARE - IT WORKS.  Hopefully we won't get bitten by any bugs (being the
>.0 revision without any maintenance patches yet.)
>
>I want to thank everyone who posted messages about my problem.  I sure did
>learn a bunch about WAN performance.  I hope that posting my results will
>help somebody else  in their endevors.
>
>Kevin  Wydra.
>Custom MIcro Systems
>
>
>
>Kevin Wydra wrote in message ...
>>Hello SQLAnywhere Pro's !!!
>>
>>I have a client that uses our application (PB60 App) against a 20MB
>>SQLAnywhere (5.5.04) database (they are a new client - normally the
>database
>>would be about 100 - 200 MB)  running on Windows NT.  Performance has been
>>great.  They just linked up to another office of theirs via a Fractional
T1
>>line (384K pipe).  There will be 8 additional users that will access the
>>database remotely.  There are 10 people accessing the database locally.
>The
>>NT Server is a Pentium 400 with 256MB Ram.
>>
>>The WAN has been completed and they are starting to test our app (which
>>resides on the workstations remotely) connecting to the database through
>the
>>384K channel. The response time is AWFUL!!!  A SELECT statement that
>returns
>>7 rows with 15 columns takes over 30 seconds.  Locally it takes about 1
>>second.  This is with only one user connected to the database #/#/
>>
>>Here is that strange part!  The phone company is monitoring the line and
>the
>>banwidth saturation has not been greater than 20%.  I don't get it. Why is
>>it Soooo slow??
>>
>>Here is what I have tried thus far:
>>I have increased the packet size on both the SQLAnywhere Server and client
>>from the default of 512K to 1500k. This did not work.
>>
>>I also tried setting the tcpip parameters {sendbuffersize and
>>receivebuffersize}.  I increased these from the default of 64k to 128k.
>>
>>Changing these settings actually made things worse.
>>
>>I have changed the Cache setting from 2MB to 4MB to 8MB.  NO difference.
>>
>>The only protocal that they are running on the NT  Server is TCPIP ( no
>IPX)
>>
>>I'm baffled.  I could see if the bandwith saturation were higher but it
has
>>only hit 20%.
>>
>>Any Ideas ???
>>
>>
>>
>>
>
>


0
Dave
9/11/1998 9:48:28 PM
>BUTTTTT !!!! Let there be LIGHT.  As a last possibility the guys at Sybase
>told me to download the 6.0 Adaptive Server Anywhere product and see if
>there was any difference.  THERE WAS A HUGE DIFFERENCE.  On an average size
>select statement a workstation over the WAN is only about 1-2 seconds slower
>than on one of the local workstations !!!!!    I could not believe it.  I
>can't figure out what they are doing different in the communications BUT I
>DONT CARE - IT WORKS.  Hopefully we won't get bitten by any bugs (being the
>.0 revision without any maintenance patches yet.)

That's good news.  They completely reworked the comm layer in version 6, so I'm not surprised that
you got different results.  But I am surprised that they couldn't figure out the version 5 problem. 

Good luck and thanks for the posting. 


Leo Tohill - Team Powersoft
-- Please post in newsgroup, not via email <
0
leotohill
9/11/1998 9:54:13 PM
Reply:

Similar Artilces:

sqlanywhere and sqlanywhere server
Currently i am using sqlanywhere and powerbuilder tool as my system development. And i am developing a standalone system. Let say, if i want to migrate my standalone system to client-server system, how do i do that? I heard that i need to have sqlanywhere(server engine) to deploy my system as client-server system. If so, do i need to install sqlanywhere(server engine) into window NT or just normal pc(treat as server). For client-server system, do i need to install sqlanywhere server at server and sqlanywhere client as normal pc where my program is installed? Could someone tell me where...

Performance about SQLAnywhere
Currently I have a SQLAnywhere database of size over 250Mb. We have a program written in PB to retrieve data from it, but that program slowed down gradually after we increased the volume of data from 100Mb to its current size. Is this a limitation of SQLAnywhere, or just my machine? Is there any fine tuning possible? The configuration of my machine is Pentium III, 128Mb RAM, 10G HD. If you have allocated sufficient cache to the database (should be at least 25mb, and 64mb would be good) then the remaining suspect would be a table scan somewhere. Have all database-related functio...

sqlanywhere vs. sqlanywhere.generel
What is the difference between the newsgroups sqlanywhere and sqlanywhere.general? Markus, There is no difference. We are working on consolidating the duplicate newsgroups. Watch for notices, it will tell you where the combined newsgroup will end up. Cheers, Jonathan Markus KARG wrote: > What is the difference between the newsgroups sqlanywhere and > sqlanywhere.general? > > -- Jonathan Baker Director, Sybase Developers Network (SDN) Sybase, Inc. http://www.sybase.com/developer bakerj@sybase.com Jonathan, in order to clarify:...

SQLAnywhere performance
I have a SQLANywhere db running on a Netware v 3.12 server. The database performed well as a stand-alone db but when moved to the network performance is lousy. Where do I look for answers/solutions to this problem? thanks How lousy? What part is lousy? You can't expect multiple row retrieves to perform the same in both a network and standalone environment. ...

Migration from SQLAnywhere 10 to SQLAnywhere 11
Do I need to migrate the database file if i want to migrate my application from SQLAnywhere 10 to SQLAnywhere 11? or a databse file created by SQLAnywhere10 will run fine under SQLAnywhere 11? Jorge, From: http://dcx.sybase.com/index.php#http%3A%2F%2Fdcx.sybase.com%2F1100en%2Fsachanges_en11%2Fv10upgrade-up-sql-any-123456.html ======== Upgrading version 10.0.0 and later databases If you are upgrading from version 10.0.0 or later, you can either use the Upgrade utility or rebuild your database. Upgrading or rebuilding is an optional step because the version 11 software ...

sqlanywhere performance improvement
Hi, 1. Does anyone know how I can rebuild indexes in a sqlanywhere database. 2. can anyone tell me how to see how the optimizer searches for the best path, if he uses his indexes properly, ... 3. Is there a possibility to view all sql-statements that are executed on the database, with there execution time? Thanks in advance ! Xavier Xavier Keters wrote: > > Hi, > > 1. Does anyone know how I can rebuild indexes in a sqlanywhere database. IF EXISTS(SELECT name FROM sysindexes WHERE name='MyIndexName') DROP INDEX MyTableName.MyIndexName GO ...

About SQLAnywhere...
Hello, I�ve developed a program with PowerBuilder 6.5 and the Sybase SQL Anywhere engine. I have a question: Can I distribuit my application with these engine?, or I have to obtain a license por each machine for instalation?. Thanks in advance On Thu, 26 Nov 1998 17:45:30 -0600, in powersoft.public.powerbuilder.general Oscar Miranda <omiranda@sia.com.mx> wrote: >Hello, I�ve developed a program with PowerBuilder 6.5 and the Sybase SQL >Anywhere engine. I have a question: Can I distribuit my application with >these engine?, or I have to obtain a license por ea...

SQLAnywhere performance problem
We have a complicated general performance problem in SQL Anywhere: The problem only occurs when retrieveing data to a datawindow in Powerbuilder (both 5.04 and 6.0) from a SQL Anywhere (5.5) database. Not with other databases and not when retrieveing the same data in another way (Embedded SQL with cursor). Large packets of what seems to be garbage data is sent from the client to the server in between small packets of real data from the server to the client. In fact more data is sent from the client than what is received (by a factor of four). We�re only reading data, no updates, ...

Sqlanywhere.general missing?
I have not been able to get to the sqlanywhere.general news group in a couple of weeks now. Has something changed? The newsgroups have moved to a new server. You will need to reset your news. -- Joshua Savill , SYBASE iAnywhere Solutions - Technical Support "James L. Blackburn" <jamesb@round2consulting.com> wrote in message news:il739v4jhptn8f7knlko9h5bk2pcjm9l08@4ax.com... > I have not been able to get to the sqlanywhere.general news group in a > couple of weeks now. Has something changed? > > Same name, different IP address. It co...

Experience with SqlAnywhere over a WAN
I woud like to say about my experience with sending many rows (doing many inserts) from client machine to server over a WAN. I testing very carefull powerbuilder pipelines and: When I sending rows from client to server by pipeline in PB6.0 Application working on client (client retrieve data from standalone database at local machine and sending to server over VAN) and tha same rows were importing from serwer to client that needed time to transfer the same number of rows was like 3:1. I mean client importing rows from server and inserts to local database three times faster then...

SQLAnywhere-performance-problem
We are using a windows-software for dialysis units based on an SQLAnywhere 5.505 Server running under Novell 5.0 ( SP5). After the last software-update we have performance-problems using a few querys ( server-utilisation more than 90%, poor performance of the query-lasting 2-3 times longer etc. ). Now the software-house told us, that the performance of the Novell-version oft ASA 5.505 would be much lower ( using the same hardware ) than the windows-version and we should switch our server to W2K ( or switch to ASA 7.02 and use SMP under W2K additionally! ). We do not know what to...

SQLAnywhere performance problem
We have a complicated general performance problem in SQL Anywhere: The problem only occurs when retrieveing data to a datawindow in Powerbuilder (both 5.04 and 6.0) from a SQL Anywhere (5.5) database. Not with other databases and not when retrieveing the same data in another way (Embedded SQL with cursor). Large packets of what seems to be garbage data is sent from the client to the server in between small packets of real data from the server to the client. In fact more data is sent from the client than what is received (by a factor of four). We�re only reading data, no update...

getting error after upgrading from sqlanywhere 7 to sqlanywhere 9
i'm using sybase sql server any where 7 and by using dbsrv7.exe i'm able to create db. it's working fine. no issues. now i'm upgrading to sybase sql server any where 9 and by using dbsrv9.exe i created db. this time when i'm using sysindexes table of sybase i'm getting error as Table name 'sysindexes' is ambiguous exception com.sybase.jdbc2.jdbc.SybSQLException because ASA Error -852: Table name 'sysindexes' is ambiguous com.sybase.jdbc2.jdbc.SybSQLException: ASA Error -852: Table name 'sysindexes' is ambiguous at com.sybase.jdbc2...

Update Fails to SQLAnywhere, but PB/ODBC/SQLAnywhere returns Success...
I recently dropped a reply in the SQLAnywhere Newsgroup regarding the question of "Death by Curly Brackets" and am not even sure the problem we're experiencing is related, BUT basically, if we have a variable in an SQLA table of type "char" and then declare an internal host variable in Powerbuilder 6.0, and execute an Insert or an Update against the table, PB and/or SQLA both return success, but the table DOES NOT get updated... here's futher details... Check out the ODBC dump below, is this a bug in PB, ODBC, SQLAnywhere or ALL of the above ANY HELP IS ...

Web resources about - SQLAnywhere performance over a WAN - sybase.sqlanywhere.general

IBM Tivoli Storage Manager - Wikipedia, the free encyclopedia
IBM Tivoli Storage Manager ( TSM or ITSM ) is a centralized, policy-based, enterprise class, data backup and recovery package. The software enables ...

Archives - Caelum's Blog
Caelum's Blog Random Stuff Navigation Home - Articles Tags 256colors 64 64bit 8 activeperl activestate advent ajax alsa amd64 asa asus automation ...

keynote bingo - Google Search
Search Images Maps Play YouTube News Gmail Drive More Calendar Translate Mobile Books Wallet Shopping Blogger Finance Photos Videos Even more ...

Mobile and Wireless Partners - Partners - Sybase Inc
Thanks for visiting the Partners section of Sybase.com. Here you will find information about Mobile and Wireless Partners - Partners. For more ...

Datensynchronisierung - sqlanywhere
„Good Partner - quick and reliable answers! Fast "delivery" by Email. Everybody can count on them." Tímea Steigervald, Product Manager Kvazar-Micro ...

Browse file extension list beginning with letter A
Browse file extension list beginning with letter A - File-Extensions.org search page

OpenLink ODBC Adapter for Ruby on Rails: OpenLink ODBC Adapter for Ruby on Rails: Downloads
OpenLink ODBC Adapter for Ruby on Rails: OpenLink ODBC Adapter for Ruby on Rails: Downloads

Developer Edition - sqlanywhere
„Good Partner - quick and reliable answers! Fast "delivery" by Email. Everybody can count on them." Tímea Steigervald, Product Manager Kvazar-Micro ...

IBM - sqlanywhere
„Good Partner - quick and reliable answers! Fast "delivery" by Email. Everybody can count on them." Tímea Steigervald, Product Manager Kvazar-Micro ...

Datenaustausch - sqlanywhere
„Good Partner - quick and reliable answers! Fast "delivery" by Email. Everybody can count on them." Tímea Steigervald, Product Manager Kvazar-Micro ...

Resources last updated: 1/7/2016 5:42:32 PM