Sybase NNTP forums - End Of Life (EOL)

The NNTP forums from Sybase - forums.sybase.com - are now closed.

All new questions should be directed to the appropriate forum at the SAP Community Network (SCN).

Individual products have links to the respective forums on SCN, or you can go to SCN and search for your product in the search box (upper right corner) to find your specific developer center.

PROXY TABLE behaves different to BASE TABLE

13 posts in General Discussion (old) Last posting was on 2009-01-12 08:15:16.0Z
Markus KARG Posted on 2008-11-06 09:24:41.0Z
From: "Markus KARG" <karg@quipsy.de>
Newsgroups: sybase.public.sqlanywhere
Subject: PROXY TABLE behaves different to BASE TABLE
Lines: 40
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.5512
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
NNTP-Posting-Host: vip152.sybase.com
X-Original-NNTP-Posting-Host: vip152.sybase.com
Message-ID: <4912b7d9@forums-1-dub>
Date: 6 Nov 2008 01:24:41 -0800
X-Trace: forums-1-dub 1225963481 10.22.241.152 (6 Nov 2008 01:24:41 -0800)
X-Original-Trace: 6 Nov 2008 01:24:41 -0800, vip152.sybase.com
X-Authenticated-User: panorama
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub sybase.public.sqlanywhere:217
Article PK: 866660

Dear SA Community,

today I'd like to report a very weird effect I just noticed in SA 11.

I am not yet able to reproduce it in a clean lab environment but only in my
huge enterprise application, but there I can reproduce it absolutely
reliably.

I noticed that sometimes a simple JDBC statement "SELECT pk, text FROM
MyProxy WHERE text = ?" called with param1 set to "A" returns a value of B
for the same column, what is a paradoxon, since the query obviously must
return the same value that was provided as a parameter. The strange thing
is:

* It works absolutely correct with BASE tables. The weird behaviour happens
only with PROXY tables and VIEWS on PROXY tables.
* It happens NOT in a standalone program but only inside of an application
server (I assume that it will also happen inside of a standalone program as
soon as I find out the exact JDBC sequence used by the application server).
This is the reason why not reporting it as a bug so far. In fact, an
application server cannot be the reason as it works pretty well as soon as I
am using BASE tables, and JDBC doesn't have a feature that allows the
application server to find out about whether it is a BASE or a PROXY table.
* It happens only if the WHERE-column is NOT the primary key (it works
absolutely well if the WHERE-column is the primary key).
* It happens with pure random: The returned value is different at each call
(but always an existing value of the queried column).

I tried many times: Not changing the application or application server, but
just replacing the PROXY by a BASE table (containing the exact same values!)
and vice versa. It is absolutely reproducible that BASE tables work well
while PROXY tables return pure random!

Can anybody tell me why this will happen? Is that a bug or is it my fault?
Any ideas?

Thanks!
Markus


"Volker Barth" <No_VBarth Posted on 2008-11-11 09:02:24.0Z
From: "Volker Barth" <No_VBarth@Spam_GLOBAL-FINANZ.de>
Newsgroups: sybase.public.sqlanywhere
References: <4912b7d9@forums-1-dub>
Subject: Re: PROXY TABLE behaves different to BASE TABLE
Lines: 66
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1933
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1933
NNTP-Posting-Host: vip152.sybase.com
X-Original-NNTP-Posting-Host: vip152.sybase.com
Message-ID: <49194a20@forums-1-dub>
Date: 11 Nov 2008 01:02:24 -0800
X-Trace: forums-1-dub 1226394144 10.22.241.152 (11 Nov 2008 01:02:24 -0800)
X-Original-Trace: 11 Nov 2008 01:02:24 -0800, vip152.sybase.com
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub sybase.public.sqlanywhere:218
Article PK: 866665

Markus,

I can't comment whether there is a difference or not, but would suggest that
you try to "debug" the remote connection with the help of cis_option:

SET OPTION cis_option = 7;

That may give you more insight as the server log (-o ....) will contain what
statement exaclty the remote server has to execute.

HTH
Volker

"Markus KARG" <karg@quipsy.de> wrote in news:4912b7d9@forums-1-dub...
> Dear SA Community,
>
> today I'd like to report a very weird effect I just noticed in SA 11.
>
> I am not yet able to reproduce it in a clean lab environment but only in
my
> huge enterprise application, but there I can reproduce it absolutely
> reliably.
>
> I noticed that sometimes a simple JDBC statement "SELECT pk, text FROM
> MyProxy WHERE text = ?" called with param1 set to "A" returns a value of B
> for the same column, what is a paradoxon, since the query obviously must
> return the same value that was provided as a parameter. The strange thing
> is:
>
> * It works absolutely correct with BASE tables. The weird behaviour
happens
> only with PROXY tables and VIEWS on PROXY tables.
> * It happens NOT in a standalone program but only inside of an application
> server (I assume that it will also happen inside of a standalone program
as
> soon as I find out the exact JDBC sequence used by the application
server).
> This is the reason why not reporting it as a bug so far. In fact, an
> application server cannot be the reason as it works pretty well as soon as
I
> am using BASE tables, and JDBC doesn't have a feature that allows the
> application server to find out about whether it is a BASE or a PROXY
table.
> * It happens only if the WHERE-column is NOT the primary key (it works
> absolutely well if the WHERE-column is the primary key).
> * It happens with pure random: The returned value is different at each
call
> (but always an existing value of the queried column).
>
> I tried many times: Not changing the application or application server,
but
> just replacing the PROXY by a BASE table (containing the exact same
values!)
> and vice versa. It is absolutely reproducible that BASE tables work well
> while PROXY tables return pure random!
>
> Can anybody tell me why this will happen? Is that a bug or is it my fault?
> Any ideas?
>
> Thanks!
> Markus
>
>


Markus KARG Posted on 2008-11-11 11:25:58.0Z
From: "Markus KARG" <karg@quipsy.de>
Newsgroups: sybase.public.sqlanywhere
References: <4912b7d9@forums-1-dub> <49194a20@forums-1-dub>
Subject: Re: PROXY TABLE behaves different to BASE TABLE
Lines: 78
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.5512
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
X-RFC2646: Format=Flowed; Original
NNTP-Posting-Host: vip152.sybase.com
X-Original-NNTP-Posting-Host: vip152.sybase.com
Message-ID: <49196bc6$1@forums-1-dub>
Date: 11 Nov 2008 03:25:58 -0800
X-Trace: forums-1-dub 1226402758 10.22.241.152 (11 Nov 2008 03:25:58 -0800)
X-Original-Trace: 11 Nov 2008 03:25:58 -0800, vip152.sybase.com
X-Authenticated-User: panorama
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub sybase.public.sqlanywhere:219
Article PK: 866662

And what exactly shall I check for in that log?

"Volker Barth" <No_VBarth@Spam_GLOBAL-FINANZ.de> schrieb im Newsbeitrag
news:49194a20@forums-1-dub...

> Markus,
>
> I can't comment whether there is a difference or not, but would suggest
> that
> you try to "debug" the remote connection with the help of cis_option:
>
> SET OPTION cis_option = 7;
>
> That may give you more insight as the server log (-o ....) will contain
> what
> statement exaclty the remote server has to execute.
>
> HTH
> Volker
>
>
> "Markus KARG" <karg@quipsy.de> wrote in news:4912b7d9@forums-1-dub...
>> Dear SA Community,
>>
>> today I'd like to report a very weird effect I just noticed in SA 11.
>>
>> I am not yet able to reproduce it in a clean lab environment but only in
> my
>> huge enterprise application, but there I can reproduce it absolutely
>> reliably.
>>
>> I noticed that sometimes a simple JDBC statement "SELECT pk, text FROM
>> MyProxy WHERE text = ?" called with param1 set to "A" returns a value of
>> B
>> for the same column, what is a paradoxon, since the query obviously must
>> return the same value that was provided as a parameter. The strange thing
>> is:
>>
>> * It works absolutely correct with BASE tables. The weird behaviour
> happens
>> only with PROXY tables and VIEWS on PROXY tables.
>> * It happens NOT in a standalone program but only inside of an
>> application
>> server (I assume that it will also happen inside of a standalone program
> as
>> soon as I find out the exact JDBC sequence used by the application
> server).
>> This is the reason why not reporting it as a bug so far. In fact, an
>> application server cannot be the reason as it works pretty well as soon
>> as
> I
>> am using BASE tables, and JDBC doesn't have a feature that allows the
>> application server to find out about whether it is a BASE or a PROXY
> table.
>> * It happens only if the WHERE-column is NOT the primary key (it works
>> absolutely well if the WHERE-column is the primary key).
>> * It happens with pure random: The returned value is different at each
> call
>> (but always an existing value of the queried column).
>>
>> I tried many times: Not changing the application or application server,
> but
>> just replacing the PROXY by a BASE table (containing the exact same
> values!)
>> and vice versa. It is absolutely reproducible that BASE tables work well
>> while PROXY tables return pure random!
>>
>> Can anybody tell me why this will happen? Is that a bug or is it my
>> fault?
>> Any ideas?
>>
>> Thanks!
>> Markus
>>
>>
>
>


"Volker Barth" <No_VBarth Posted on 2008-11-11 11:55:24.0Z
From: "Volker Barth" <No_VBarth@Spam_GLOBAL-FINANZ.de>
Newsgroups: sybase.public.sqlanywhere
References: <4912b7d9@forums-1-dub> <49194a20@forums-1-dub> <49196bc6$1@forums-1-dub>
Subject: Re: PROXY TABLE behaves different to BASE TABLE
Lines: 104
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1933
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1933
NNTP-Posting-Host: vip152.sybase.com
X-Original-NNTP-Posting-Host: vip152.sybase.com
Message-ID: <491972ac@forums-1-dub>
Date: 11 Nov 2008 03:55:24 -0800
X-Trace: forums-1-dub 1226404524 10.22.241.152 (11 Nov 2008 03:55:24 -0800)
X-Original-Trace: 11 Nov 2008 03:55:24 -0800, vip152.sybase.com
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub sybase.public.sqlanywhere:220
Article PK: 866663

Markus,

AFAIK, the statement to the remote database will be shown there exactly.
That could give you any hint if the OMNI layer might rewrite your statement
to something unexpected. Though I'm not sure how parameter values are
handled (and logged) in this respect. If they just appear as '?' then you
won't get further hints whether they are passed unchanged. But then you
might test with SELECT with a literal instead of parameters.

In my humble experience, the CIS_OPTION has been quite helpful with proxy
tables, e.g. to make sure that a statement is completely passed to the
remote server instead of a slow interaction of local and remote data, or
that a SELECT with a SQL function is really using this function on the
remote side, too.

Volker

"Markus KARG" <karg@quipsy.de> wrote in news:49196bc6$1@forums-1-dub...
> And what exactly shall I check for in that log?
>
> "Volker Barth" <No_VBarth@Spam_GLOBAL-FINANZ.de> schrieb im Newsbeitrag
> news:49194a20@forums-1-dub...
> > Markus,
> >
> > I can't comment whether there is a difference or not, but would suggest
> > that
> > you try to "debug" the remote connection with the help of cis_option:
> >
> > SET OPTION cis_option = 7;
> >
> > That may give you more insight as the server log (-o ....) will contain
> > what
> > statement exaclty the remote server has to execute.
> >
> > HTH
> > Volker
> >
> >
> > "Markus KARG" <karg@quipsy.de> wrote in news:4912b7d9@forums-1-dub...
> >> Dear SA Community,
> >>
> >> today I'd like to report a very weird effect I just noticed in SA 11.
> >>
> >> I am not yet able to reproduce it in a clean lab environment but only
in
> > my
> >> huge enterprise application, but there I can reproduce it absolutely
> >> reliably.
> >>
> >> I noticed that sometimes a simple JDBC statement "SELECT pk, text FROM
> >> MyProxy WHERE text = ?" called with param1 set to "A" returns a value
of
> >> B
> >> for the same column, what is a paradoxon, since the query obviously
must
> >> return the same value that was provided as a parameter. The strange
thing
> >> is:
> >>
> >> * It works absolutely correct with BASE tables. The weird behaviour
> > happens
> >> only with PROXY tables and VIEWS on PROXY tables.
> >> * It happens NOT in a standalone program but only inside of an
> >> application
> >> server (I assume that it will also happen inside of a standalone
program
> > as
> >> soon as I find out the exact JDBC sequence used by the application
> > server).
> >> This is the reason why not reporting it as a bug so far. In fact, an
> >> application server cannot be the reason as it works pretty well as soon
> >> as
> > I
> >> am using BASE tables, and JDBC doesn't have a feature that allows the
> >> application server to find out about whether it is a BASE or a PROXY
> > table.
> >> * It happens only if the WHERE-column is NOT the primary key (it works
> >> absolutely well if the WHERE-column is the primary key).
> >> * It happens with pure random: The returned value is different at each
> > call
> >> (but always an existing value of the queried column).
> >>
> >> I tried many times: Not changing the application or application server,
> > but
> >> just replacing the PROXY by a BASE table (containing the exact same
> > values!)
> >> and vice versa. It is absolutely reproducible that BASE tables work
well
> >> while PROXY tables return pure random!
> >>
> >> Can anybody tell me why this will happen? Is that a bug or is it my
> >> fault?
> >> Any ideas?
> >>
> >> Thanks!
> >> Markus
> >>
> >>
> >
> >
>
>


Markus KARG Posted on 2008-11-15 16:43:15.0Z
From: "Markus KARG" <karg@quipsy.de>
Newsgroups: sybase.public.sqlanywhere
References: <4912b7d9@forums-1-dub> <49194a20@forums-1-dub> <49196bc6$1@forums-1-dub> <491972ac@forums-1-dub>
Subject: Re: PROXY TABLE behaves different to BASE TABLE
Lines: 122
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.5512
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
X-RFC2646: Format=Flowed; Original
NNTP-Posting-Host: vip152.sybase.com
X-Original-NNTP-Posting-Host: vip152.sybase.com
Message-ID: <491efc23@forums-1-dub>
Date: 15 Nov 2008 08:43:15 -0800
X-Trace: forums-1-dub 1226767395 10.22.241.152 (15 Nov 2008 08:43:15 -0800)
X-Original-Trace: 15 Nov 2008 08:43:15 -0800, vip152.sybase.com
X-Authenticated-User: panorama
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub sybase.public.sqlanywhere:221
Article PK: 866664

Volker,

since what I execute is a simple "SELECT x, y FROM Table z WHERE y = ?" I
doubt that anything that I find in the log can be a help: What shall I do if
any fancy stuff is found in the log instead of the above SQL? I cannot
change it at all. So what shall it be good for, investing hours to check the
log? What do you expect to find there that I personally could change?

Thanks
Markus

"Volker Barth" <No_VBarth@Spam_GLOBAL-FINANZ.de> schrieb im Newsbeitrag
news:491972ac@forums-1-dub...

> Markus,
>
> AFAIK, the statement to the remote database will be shown there exactly.
> That could give you any hint if the OMNI layer might rewrite your
> statement
> to something unexpected. Though I'm not sure how parameter values are
> handled (and logged) in this respect. If they just appear as '?' then you
> won't get further hints whether they are passed unchanged. But then you
> might test with SELECT with a literal instead of parameters.
>
> In my humble experience, the CIS_OPTION has been quite helpful with proxy
> tables, e.g. to make sure that a statement is completely passed to the
> remote server instead of a slow interaction of local and remote data, or
> that a SELECT with a SQL function is really using this function on the
> remote side, too.
>
> Volker
>
> "Markus KARG" <karg@quipsy.de> wrote in news:49196bc6$1@forums-1-dub...
>> And what exactly shall I check for in that log?
>>
>> "Volker Barth" <No_VBarth@Spam_GLOBAL-FINANZ.de> schrieb im Newsbeitrag
>> news:49194a20@forums-1-dub...
>> > Markus,
>> >
>> > I can't comment whether there is a difference or not, but would suggest
>> > that
>> > you try to "debug" the remote connection with the help of cis_option:
>> >
>> > SET OPTION cis_option = 7;
>> >
>> > That may give you more insight as the server log (-o ....) will contain
>> > what
>> > statement exaclty the remote server has to execute.
>> >
>> > HTH
>> > Volker
>> >
>> >
>> > "Markus KARG" <karg@quipsy.de> wrote in news:4912b7d9@forums-1-dub...
>> >> Dear SA Community,
>> >>
>> >> today I'd like to report a very weird effect I just noticed in SA 11.
>> >>
>> >> I am not yet able to reproduce it in a clean lab environment but only
> in
>> > my
>> >> huge enterprise application, but there I can reproduce it absolutely
>> >> reliably.
>> >>
>> >> I noticed that sometimes a simple JDBC statement "SELECT pk, text FROM
>> >> MyProxy WHERE text = ?" called with param1 set to "A" returns a value
> of
>> >> B
>> >> for the same column, what is a paradoxon, since the query obviously
> must
>> >> return the same value that was provided as a parameter. The strange
> thing
>> >> is:
>> >>
>> >> * It works absolutely correct with BASE tables. The weird behaviour
>> > happens
>> >> only with PROXY tables and VIEWS on PROXY tables.
>> >> * It happens NOT in a standalone program but only inside of an
>> >> application
>> >> server (I assume that it will also happen inside of a standalone
> program
>> > as
>> >> soon as I find out the exact JDBC sequence used by the application
>> > server).
>> >> This is the reason why not reporting it as a bug so far. In fact, an
>> >> application server cannot be the reason as it works pretty well as
>> >> soon
>> >> as
>> > I
>> >> am using BASE tables, and JDBC doesn't have a feature that allows the
>> >> application server to find out about whether it is a BASE or a PROXY
>> > table.
>> >> * It happens only if the WHERE-column is NOT the primary key (it works
>> >> absolutely well if the WHERE-column is the primary key).
>> >> * It happens with pure random: The returned value is different at each
>> > call
>> >> (but always an existing value of the queried column).
>> >>
>> >> I tried many times: Not changing the application or application
>> >> server,
>> > but
>> >> just replacing the PROXY by a BASE table (containing the exact same
>> > values!)
>> >> and vice versa. It is absolutely reproducible that BASE tables work
> well
>> >> while PROXY tables return pure random!
>> >>
>> >> Can anybody tell me why this will happen? Is that a bug or is it my
>> >> fault?
>> >> Any ideas?
>> >>
>> >> Thanks!
>> >> Markus
>> >>
>> >>
>> >
>> >
>>
>>
>
>


Arthur Hefti Posted on 2008-11-16 06:50:58.0Z
From: "Arthur Hefti" <arthur@catsoft.ch>
Newsgroups: sybase.public.sqlanywhere
References: <4912b7d9@forums-1-dub> <49194a20@forums-1-dub> <49196bc6$1@forums-1-dub> <491972ac@forums-1-dub> <491efc23@forums-1-dub>
Subject: Re: PROXY TABLE behaves different to BASE TABLE
Lines: 148
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.5512
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
X-RFC2646: Format=Flowed; Response
NNTP-Posting-Host: vip152.sybase.com
X-Original-NNTP-Posting-Host: vip152.sybase.com
Message-ID: <491fc2d2$1@forums-1-dub>
Date: 15 Nov 2008 22:50:58 -0800
X-Trace: forums-1-dub 1226818258 10.22.241.152 (15 Nov 2008 22:50:58 -0800)
X-Original-Trace: 15 Nov 2008 22:50:58 -0800, vip152.sybase.com
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub sybase.public.sqlanywhere:222
Article PK: 841531

Markus

what's the point in putting the question in the newsgroup if you don't want
to try to find a solution based on suggestions of other members? Call Sybase
and ask for support. They might even send somebody to your place who sets
the suggested options and gives a look at the logs (depending on how much
your willing to pay).

Otherwise apply the cis_option and execute the query that makes the
troubles. Check the server log or server window of the remote db. If the
query is not the same, report it as bug to Sybase. If the query is the same,
execute the query directly on the remote database and compare the results.
Report a bug do Sybase if they differ.

Arthur

"Markus KARG" <karg@quipsy.de> wrote in message
news:491efc23@forums-1-dub...
> Volker,
>
> since what I execute is a simple "SELECT x, y FROM Table z WHERE y = ?" I
> doubt that anything that I find in the log can be a help: What shall I do
> if any fancy stuff is found in the log instead of the above SQL? I cannot
> change it at all. So what shall it be good for, investing hours to check
> the log? What do you expect to find there that I personally could change?
>
> Thanks
> Markus
>
> "Volker Barth" <No_VBarth@Spam_GLOBAL-FINANZ.de> schrieb im Newsbeitrag
> news:491972ac@forums-1-dub...
>> Markus,
>>
>> AFAIK, the statement to the remote database will be shown there exactly.
>> That could give you any hint if the OMNI layer might rewrite your
>> statement
>> to something unexpected. Though I'm not sure how parameter values are
>> handled (and logged) in this respect. If they just appear as '?' then you
>> won't get further hints whether they are passed unchanged. But then you
>> might test with SELECT with a literal instead of parameters.
>>
>> In my humble experience, the CIS_OPTION has been quite helpful with proxy
>> tables, e.g. to make sure that a statement is completely passed to the
>> remote server instead of a slow interaction of local and remote data, or
>> that a SELECT with a SQL function is really using this function on the
>> remote side, too.
>>
>> Volker
>>
>> "Markus KARG" <karg@quipsy.de> wrote in news:49196bc6$1@forums-1-dub...
>>> And what exactly shall I check for in that log?
>>>
>>> "Volker Barth" <No_VBarth@Spam_GLOBAL-FINANZ.de> schrieb im Newsbeitrag
>>> news:49194a20@forums-1-dub...
>>> > Markus,
>>> >
>>> > I can't comment whether there is a difference or not, but would
>>> > suggest
>>> > that
>>> > you try to "debug" the remote connection with the help of cis_option:
>>> >
>>> > SET OPTION cis_option = 7;
>>> >
>>> > That may give you more insight as the server log (-o ....) will
>>> > contain
>>> > what
>>> > statement exaclty the remote server has to execute.
>>> >
>>> > HTH
>>> > Volker
>>> >
>>> >
>>> > "Markus KARG" <karg@quipsy.de> wrote in news:4912b7d9@forums-1-dub...
>>> >> Dear SA Community,
>>> >>
>>> >> today I'd like to report a very weird effect I just noticed in SA 11.
>>> >>
>>> >> I am not yet able to reproduce it in a clean lab environment but only
>> in
>>> > my
>>> >> huge enterprise application, but there I can reproduce it absolutely
>>> >> reliably.
>>> >>
>>> >> I noticed that sometimes a simple JDBC statement "SELECT pk, text
>>> >> FROM
>>> >> MyProxy WHERE text = ?" called with param1 set to "A" returns a value
>> of
>>> >> B
>>> >> for the same column, what is a paradoxon, since the query obviously
>> must
>>> >> return the same value that was provided as a parameter. The strange
>> thing
>>> >> is:
>>> >>
>>> >> * It works absolutely correct with BASE tables. The weird behaviour
>>> > happens
>>> >> only with PROXY tables and VIEWS on PROXY tables.
>>> >> * It happens NOT in a standalone program but only inside of an
>>> >> application
>>> >> server (I assume that it will also happen inside of a standalone
>> program
>>> > as
>>> >> soon as I find out the exact JDBC sequence used by the application
>>> > server).
>>> >> This is the reason why not reporting it as a bug so far. In fact, an
>>> >> application server cannot be the reason as it works pretty well as
>>> >> soon
>>> >> as
>>> > I
>>> >> am using BASE tables, and JDBC doesn't have a feature that allows the
>>> >> application server to find out about whether it is a BASE or a PROXY
>>> > table.
>>> >> * It happens only if the WHERE-column is NOT the primary key (it
>>> >> works
>>> >> absolutely well if the WHERE-column is the primary key).
>>> >> * It happens with pure random: The returned value is different at
>>> >> each
>>> > call
>>> >> (but always an existing value of the queried column).
>>> >>
>>> >> I tried many times: Not changing the application or application
>>> >> server,
>>> > but
>>> >> just replacing the PROXY by a BASE table (containing the exact same
>>> > values!)
>>> >> and vice versa. It is absolutely reproducible that BASE tables work
>> well
>>> >> while PROXY tables return pure random!
>>> >>
>>> >> Can anybody tell me why this will happen? Is that a bug or is it my
>>> >> fault?
>>> >> Any ideas?
>>> >>
>>> >> Thanks!
>>> >> Markus
>>> >>
>>> >>
>>> >
>>> >
>>>
>>>
>>
>>
>
>


"Volker Barth" <No_VBarth Posted on 2008-11-17 09:49:30.0Z
From: "Volker Barth" <No_VBarth@Spam_GLOBAL-FINANZ.de>
Newsgroups: sybase.public.sqlanywhere
References: <4912b7d9@forums-1-dub> <49194a20@forums-1-dub> <49196bc6$1@forums-1-dub> <491972ac@forums-1-dub> <491efc23@forums-1-dub> <491fc2d2$1@forums-1-dub>
Subject: Re: PROXY TABLE behaves different to BASE TABLE
Lines: 74
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1933
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1933
NNTP-Posting-Host: vip152.sybase.com
X-Original-NNTP-Posting-Host: vip152.sybase.com
Message-ID: <49213e2a@forums-1-dub>
Date: 17 Nov 2008 01:49:30 -0800
X-Trace: forums-1-dub 1226915370 10.22.241.152 (17 Nov 2008 01:49:30 -0800)
X-Original-Trace: 17 Nov 2008 01:49:30 -0800, vip152.sybase.com
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub sybase.public.sqlanywhere:223
Article PK: 866666

Arthur,

thanks for seconding my suggestions. After all, we're primarily just
volunteers here.
Couldn't have said it nicer than you did:)

Best regards
Volker

"Arthur Hefti" <arthur@catsoft.ch> wrote in news:491fc2d2$1@forums-1-dub...
> Markus
>
> what's the point in putting the question in the newsgroup if you don't
want
> to try to find a solution based on suggestions of other members? Call
Sybase
> and ask for support. They might even send somebody to your place who sets
> the suggested options and gives a look at the logs (depending on how much
> your willing to pay).
>
> Otherwise apply the cis_option and execute the query that makes the
> troubles. Check the server log or server window of the remote db. If the
> query is not the same, report it as bug to Sybase. If the query is the
same,
> execute the query directly on the remote database and compare the results.
> Report a bug do Sybase if they differ.
>
> Arthur
>
>
> "Markus KARG" <karg@quipsy.de> wrote in message
> news:491efc23@forums-1-dub...
> > Volker,
> >
> > since what I execute is a simple "SELECT x, y FROM Table z WHERE y = ?"
I
> > doubt that anything that I find in the log can be a help: What shall I
do
> > if any fancy stuff is found in the log instead of the above SQL? I
cannot
> > change it at all. So what shall it be good for, investing hours to check
> > the log? What do you expect to find there that I personally could
change?
> >
> > Thanks
> > Markus
> >
> > "Volker Barth" <No_VBarth@Spam_GLOBAL-FINANZ.de> schrieb im Newsbeitrag
> > news:491972ac@forums-1-dub...
> >> Markus,
> >>
> >> AFAIK, the statement to the remote database will be shown there
exactly.
> >> That could give you any hint if the OMNI layer might rewrite your
> >> statement
> >> to something unexpected. Though I'm not sure how parameter values are
> >> handled (and logged) in this respect. If they just appear as '?' then
you
> >> won't get further hints whether they are passed unchanged. But then you

> >> might test with SELECT with a literal instead of parameters.
> >>
> >> In my humble experience, the CIS_OPTION has been quite helpful with
proxy
> >> tables, e.g. to make sure that a statement is completely passed to the
> >> remote server instead of a slow interaction of local and remote data,
or
> >> that a SELECT with a SQL function is really using this function on the
> >> remote side, too.
> >>
> >> Volker
> >>


Markus KARG Posted on 2008-11-25 14:18:32.0Z
From: "Markus KARG" <karg@quipsy.de>
Newsgroups: sybase.public.sqlanywhere
References: <4912b7d9@forums-1-dub> <49194a20@forums-1-dub> <49196bc6$1@forums-1-dub> <491972ac@forums-1-dub> <491efc23@forums-1-dub> <491fc2d2$1@forums-1-dub> <49213e2a@forums-1-dub>
Subject: Re: PROXY TABLE behaves different to BASE TABLE
Lines: 93
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.5512
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
X-RFC2646: Format=Flowed; Original
NNTP-Posting-Host: vip152.sybase.com
X-Original-NNTP-Posting-Host: vip152.sybase.com
Message-ID: <492c0938@forums-1-dub>
Date: 25 Nov 2008 06:18:32 -0800
X-Trace: forums-1-dub 1227622712 10.22.241.152 (25 Nov 2008 06:18:32 -0800)
X-Original-Trace: 25 Nov 2008 06:18:32 -0800, vip152.sybase.com
X-Authenticated-User: panorama
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub sybase.public.sqlanywhere:229
Article PK: 866672

Volker,

I respect your attempts, but in fact what I am searching for is a Sybase
member that is interesting in SOLVING the bug since German Sybase Support
just provided a workaround but was not wanting do SOLVE it. I often was
lucky that some Sybase members participated in my discussions. Also, it
MIGHT be possible that others had the same issue and know a real SOLUTION.

Regards
Markus

"Volker Barth" <No_VBarth@Spam_GLOBAL-FINANZ.de> schrieb im Newsbeitrag
news:49213e2a@forums-1-dub...

> Arthur,
>
> thanks for seconding my suggestions. After all, we're primarily just
> volunteers here.
> Couldn't have said it nicer than you did:)
>
> Best regards
> Volker
>
> "Arthur Hefti" <arthur@catsoft.ch> wrote in
> news:491fc2d2$1@forums-1-dub...
>> Markus
>>
>> what's the point in putting the question in the newsgroup if you don't
> want
>> to try to find a solution based on suggestions of other members? Call
> Sybase
>> and ask for support. They might even send somebody to your place who sets
>> the suggested options and gives a look at the logs (depending on how much
>> your willing to pay).
>>
>> Otherwise apply the cis_option and execute the query that makes the
>> troubles. Check the server log or server window of the remote db. If the
>> query is not the same, report it as bug to Sybase. If the query is the
> same,
>> execute the query directly on the remote database and compare the
>> results.
>> Report a bug do Sybase if they differ.
>>
>> Arthur
>>
>>
>> "Markus KARG" <karg@quipsy.de> wrote in message
>> news:491efc23@forums-1-dub...
>> > Volker,
>> >
>> > since what I execute is a simple "SELECT x, y FROM Table z WHERE y = ?"
> I
>> > doubt that anything that I find in the log can be a help: What shall I
> do
>> > if any fancy stuff is found in the log instead of the above SQL? I
> cannot
>> > change it at all. So what shall it be good for, investing hours to
>> > check
>> > the log? What do you expect to find there that I personally could
> change?
>> >
>> > Thanks
>> > Markus
>> >
>> > "Volker Barth" <No_VBarth@Spam_GLOBAL-FINANZ.de> schrieb im Newsbeitrag
>> > news:491972ac@forums-1-dub...
>> >> Markus,
>> >>
>> >> AFAIK, the statement to the remote database will be shown there
> exactly.
>> >> That could give you any hint if the OMNI layer might rewrite your
>> >> statement
>> >> to something unexpected. Though I'm not sure how parameter values are
>> >> handled (and logged) in this respect. If they just appear as '?' then
> you
>> >> won't get further hints whether they are passed unchanged. But then
>> >> you
>
>> >> might test with SELECT with a literal instead of parameters.
>> >>
>> >> In my humble experience, the CIS_OPTION has been quite helpful with
> proxy
>> >> tables, e.g. to make sure that a statement is completely passed to the
>> >> remote server instead of a slow interaction of local and remote data,
> or
>> >> that a SELECT with a SQL function is really using this function on the
>> >> remote side, too.
>> >>
>> >> Volker
>> >>
>
>


"Volker Barth" <No_VBarth Posted on 2008-11-28 08:34:01.0Z
From: "Volker Barth" <No_VBarth@Spam_GLOBAL-FINANZ.de>
Newsgroups: sybase.public.sqlanywhere
References: <4912b7d9@forums-1-dub> <49194a20@forums-1-dub> <49196bc6$1@forums-1-dub> <491972ac@forums-1-dub> <491efc23@forums-1-dub> <491fc2d2$1@forums-1-dub> <49213e2a@forums-1-dub> <492c0938@forums-1-dub>
Subject: Re: PROXY TABLE behaves different to BASE TABLE
Lines: 121
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1933
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1933
NNTP-Posting-Host: vip152.sybase.com
X-Original-NNTP-Posting-Host: vip152.sybase.com
Message-ID: <492facf9$1@forums-1-dub>
Date: 28 Nov 2008 00:34:01 -0800
X-Trace: forums-1-dub 1227861241 10.22.241.152 (28 Nov 2008 00:34:01 -0800)
X-Original-Trace: 28 Nov 2008 00:34:01 -0800, vip152.sybase.com
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub sybase.public.sqlanywhere:230
Article PK: 866673

Markus,

I can't tell about negative experience with Sybase tech support (and have
never used the German support so far). My few cases with the international
support teams were satisfying.

At the moment I would suggest to repost your topic in the
"sybase.public.sqlanywhere.general" NG and address the iAnywhere staff
especially. IMHO the current NG "sybase.public.sqlanywhere" gets *much*
lesser attention.

HTH
Volker

"Markus KARG" <karg@quipsy.de> wrote in news:492c0938@forums-1-dub...
> Volker,
>
> I respect your attempts, but in fact what I am searching for is a Sybase
> member that is interesting in SOLVING the bug since German Sybase Support
> just provided a workaround but was not wanting do SOLVE it. I often was
> lucky that some Sybase members participated in my discussions. Also, it
> MIGHT be possible that others had the same issue and know a real SOLUTION.
>
> Regards
> Markus
>
> "Volker Barth" <No_VBarth@Spam_GLOBAL-FINANZ.de> schrieb im Newsbeitrag
> news:49213e2a@forums-1-dub...
> > Arthur,
> >
> > thanks for seconding my suggestions. After all, we're primarily just
> > volunteers here.
> > Couldn't have said it nicer than you did:)
> >
> > Best regards
> > Volker
> >
> > "Arthur Hefti" <arthur@catsoft.ch> wrote in
> > news:491fc2d2$1@forums-1-dub...
> >> Markus
> >>
> >> what's the point in putting the question in the newsgroup if you don't
> > want
> >> to try to find a solution based on suggestions of other members? Call
> > Sybase
> >> and ask for support. They might even send somebody to your place who
sets
> >> the suggested options and gives a look at the logs (depending on how
much
> >> your willing to pay).
> >>
> >> Otherwise apply the cis_option and execute the query that makes the
> >> troubles. Check the server log or server window of the remote db. If
the
> >> query is not the same, report it as bug to Sybase. If the query is the
> > same,
> >> execute the query directly on the remote database and compare the
> >> results.
> >> Report a bug do Sybase if they differ.
> >>
> >> Arthur
> >>
> >>
> >> "Markus KARG" <karg@quipsy.de> wrote in message
> >> news:491efc23@forums-1-dub...
> >> > Volker,
> >> >
> >> > since what I execute is a simple "SELECT x, y FROM Table z WHERE y =
?"
> > I
> >> > doubt that anything that I find in the log can be a help: What shall
I
> > do
> >> > if any fancy stuff is found in the log instead of the above SQL? I
> > cannot
> >> > change it at all. So what shall it be good for, investing hours to
> >> > check
> >> > the log? What do you expect to find there that I personally could
> > change?
> >> >
> >> > Thanks
> >> > Markus
> >> >
> >> > "Volker Barth" <No_VBarth@Spam_GLOBAL-FINANZ.de> schrieb im
Newsbeitrag
> >> > news:491972ac@forums-1-dub...
> >> >> Markus,
> >> >>
> >> >> AFAIK, the statement to the remote database will be shown there
> > exactly.
> >> >> That could give you any hint if the OMNI layer might rewrite your
> >> >> statement
> >> >> to something unexpected. Though I'm not sure how parameter values
are
> >> >> handled (and logged) in this respect. If they just appear as '?'
then
> > you
> >> >> won't get further hints whether they are passed unchanged. But then
> >> >> you
> >
> >> >> might test with SELECT with a literal instead of parameters.
> >> >>
> >> >> In my humble experience, the CIS_OPTION has been quite helpful with
> > proxy
> >> >> tables, e.g. to make sure that a statement is completely passed to
the
> >> >> remote server instead of a slow interaction of local and remote
data,
> > or
> >> >> that a SELECT with a SQL function is really using this function on
the
> >> >> remote side, too.
> >> >>
> >> >> Volker
> >> >>
> >
> >
>
>


Markus KARG Posted on 2009-01-07 09:35:45.0Z
From: "Markus KARG" <karg@quipsy.de>
Newsgroups: sybase.public.sqlanywhere
References: <4912b7d9@forums-1-dub> <49194a20@forums-1-dub> <49196bc6$1@forums-1-dub> <491972ac@forums-1-dub> <491efc23@forums-1-dub> <491fc2d2$1@forums-1-dub> <49213e2a@forums-1-dub> <492c0938@forums-1-dub> <492facf9$1@forums-1-dub>
Subject: Re: PROXY TABLE behaves different to BASE TABLE
Lines: 128
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.5512
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
X-RFC2646: Format=Flowed; Original
NNTP-Posting-Host: vip152.sybase.com
X-Original-NNTP-Posting-Host: vip152.sybase.com
Message-ID: <49647771$1@forums-1-dub>
Date: 7 Jan 2009 01:35:45 -0800
X-Trace: forums-1-dub 1231320945 10.22.241.152 (7 Jan 2009 01:35:45 -0800)
X-Original-Trace: 7 Jan 2009 01:35:45 -0800, vip152.sybase.com
X-Authenticated-User: panorama
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub sybase.public.sqlanywhere:233
Article PK: 866675

BTW, what is the difference between these newsgroups?

"Volker Barth" <No_VBarth@Spam_GLOBAL-FINANZ.de> schrieb im Newsbeitrag
news:492facf9$1@forums-1-dub...

> Markus,
>
> I can't tell about negative experience with Sybase tech support (and have
> never used the German support so far). My few cases with the international
> support teams were satisfying.
>
> At the moment I would suggest to repost your topic in the
> "sybase.public.sqlanywhere.general" NG and address the iAnywhere staff
> especially. IMHO the current NG "sybase.public.sqlanywhere" gets *much*
> lesser attention.
>
> HTH
> Volker
>
> "Markus KARG" <karg@quipsy.de> wrote in news:492c0938@forums-1-dub...
>> Volker,
>>
>> I respect your attempts, but in fact what I am searching for is a Sybase
>> member that is interesting in SOLVING the bug since German Sybase Support
>> just provided a workaround but was not wanting do SOLVE it. I often was
>> lucky that some Sybase members participated in my discussions. Also, it
>> MIGHT be possible that others had the same issue and know a real
>> SOLUTION.
>>
>> Regards
>> Markus
>>
>> "Volker Barth" <No_VBarth@Spam_GLOBAL-FINANZ.de> schrieb im Newsbeitrag
>> news:49213e2a@forums-1-dub...
>> > Arthur,
>> >
>> > thanks for seconding my suggestions. After all, we're primarily just
>> > volunteers here.
>> > Couldn't have said it nicer than you did:)
>> >
>> > Best regards
>> > Volker
>> >
>> > "Arthur Hefti" <arthur@catsoft.ch> wrote in
>> > news:491fc2d2$1@forums-1-dub...
>> >> Markus
>> >>
>> >> what's the point in putting the question in the newsgroup if you don't
>> > want
>> >> to try to find a solution based on suggestions of other members? Call
>> > Sybase
>> >> and ask for support. They might even send somebody to your place who
> sets
>> >> the suggested options and gives a look at the logs (depending on how
> much
>> >> your willing to pay).
>> >>
>> >> Otherwise apply the cis_option and execute the query that makes the
>> >> troubles. Check the server log or server window of the remote db. If
> the
>> >> query is not the same, report it as bug to Sybase. If the query is the
>> > same,
>> >> execute the query directly on the remote database and compare the
>> >> results.
>> >> Report a bug do Sybase if they differ.
>> >>
>> >> Arthur
>> >>
>> >>
>> >> "Markus KARG" <karg@quipsy.de> wrote in message
>> >> news:491efc23@forums-1-dub...
>> >> > Volker,
>> >> >
>> >> > since what I execute is a simple "SELECT x, y FROM Table z WHERE y =
> ?"
>> > I
>> >> > doubt that anything that I find in the log can be a help: What shall
> I
>> > do
>> >> > if any fancy stuff is found in the log instead of the above SQL? I
>> > cannot
>> >> > change it at all. So what shall it be good for, investing hours to
>> >> > check
>> >> > the log? What do you expect to find there that I personally could
>> > change?
>> >> >
>> >> > Thanks
>> >> > Markus
>> >> >
>> >> > "Volker Barth" <No_VBarth@Spam_GLOBAL-FINANZ.de> schrieb im
> Newsbeitrag
>> >> > news:491972ac@forums-1-dub...
>> >> >> Markus,
>> >> >>
>> >> >> AFAIK, the statement to the remote database will be shown there
>> > exactly.
>> >> >> That could give you any hint if the OMNI layer might rewrite your
>> >> >> statement
>> >> >> to something unexpected. Though I'm not sure how parameter values
> are
>> >> >> handled (and logged) in this respect. If they just appear as '?'
> then
>> > you
>> >> >> won't get further hints whether they are passed unchanged. But then
>> >> >> you
>> >
>> >> >> might test with SELECT with a literal instead of parameters.
>> >> >>
>> >> >> In my humble experience, the CIS_OPTION has been quite helpful with
>> > proxy
>> >> >> tables, e.g. to make sure that a statement is completely passed to
> the
>> >> >> remote server instead of a slow interaction of local and remote
> data,
>> > or
>> >> >> that a SELECT with a SQL function is really using this function on
> the
>> >> >> remote side, too.
>> >> >>
>> >> >> Volker
>> >> >>
>> >
>> >
>>
>>
>
>


"Volker Barth" <No_VBarth Posted on 2009-01-08 08:45:45.0Z
From: "Volker Barth" <No_VBarth@Spam_GLOBAL-FINANZ.de>
Newsgroups: sybase.public.sqlanywhere
References: <4912b7d9@forums-1-dub> <49194a20@forums-1-dub> <49196bc6$1@forums-1-dub> <491972ac@forums-1-dub> <491efc23@forums-1-dub> <491fc2d2$1@forums-1-dub> <49213e2a@forums-1-dub> <492c0938@forums-1-dub> <492facf9$1@forums-1-dub> <49647771$1@forums-1-dub>
Subject: Re: PROXY TABLE behaves different to BASE TABLE
Lines: 23
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1933
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1933
NNTP-Posting-Host: vip152.sybase.com
X-Original-NNTP-Posting-Host: vip152.sybase.com
Message-ID: <4965bd39$2@forums-1-dub>
Date: 8 Jan 2009 00:45:45 -0800
X-Trace: forums-1-dub 1231404345 10.22.241.152 (8 Jan 2009 00:45:45 -0800)
X-Original-Trace: 8 Jan 2009 00:45:45 -0800, vip152.sybase.com
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub sybase.public.sqlanywhere:234
Article PK: 866677

Markus,

can't tell why there are both of them - it's irritating IMHO.
AFAIK the current NG ("sybase.public.sqlanywhere") is not even listed in the
Sybase NG forums list for SQL Anywhere, and I have only come across it by
incident. Therefore I prefer the "sybase.public.sqlanywhere.general" NG.

You may ask the question why there are both (and more) NGs in the other NG
:)

Volker

"Markus KARG" <karg@quipsy.de> wrote in news:49647771$1@forums-1-dub...
> BTW, what is the difference between these newsgroups?
>
> "Volker Barth" <No_VBarth@Spam_GLOBAL-FINANZ.de> schrieb im Newsbeitrag

> > At the moment I would suggest to repost your topic in the
> > "sybase.public.sqlanywhere.general" NG and address the iAnywhere staff
> > especially. IMHO the current NG "sybase.public.sqlanywhere" gets *much*
> > lesser attention.


Markus KARG Posted on 2009-01-12 08:15:16.0Z
From: "Markus KARG" <karg@quipsy.de>
Newsgroups: sybase.public.sqlanywhere
References: <4912b7d9@forums-1-dub> <49194a20@forums-1-dub> <49196bc6$1@forums-1-dub> <491972ac@forums-1-dub> <491efc23@forums-1-dub> <491fc2d2$1@forums-1-dub> <49213e2a@forums-1-dub> <492c0938@forums-1-dub> <492facf9$1@forums-1-dub> <49647771$1@forums-1-dub> <4965bd39$2@forums-1-dub>
Subject: Re: PROXY TABLE behaves different to BASE TABLE
Lines: 35
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.5512
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
X-RFC2646: Format=Flowed; Original
NNTP-Posting-Host: vip152.sybase.com
X-Original-NNTP-Posting-Host: vip152.sybase.com
Message-ID: <496afc14$1@forums-1-dub>
Date: 12 Jan 2009 00:15:16 -0800
X-Trace: forums-1-dub 1231748116 10.22.241.152 (12 Jan 2009 00:15:16 -0800)
X-Original-Trace: 12 Jan 2009 00:15:16 -0800, vip152.sybase.com
X-Authenticated-User: panorama
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub sybase.public.sqlanywhere:235
Article PK: 866679

Volker,

ok, see you in the other NG.

bye
Markus

"Volker Barth" <No_VBarth@Spam_GLOBAL-FINANZ.de> schrieb im Newsbeitrag
news:4965bd39$2@forums-1-dub...

> Markus,
>
> can't tell why there are both of them - it's irritating IMHO.
> AFAIK the current NG ("sybase.public.sqlanywhere") is not even listed in
> the
> Sybase NG forums list for SQL Anywhere, and I have only come across it by
> incident. Therefore I prefer the "sybase.public.sqlanywhere.general" NG.
>
> You may ask the question why there are both (and more) NGs in the other NG
> :)
>
> Volker
>
> "Markus KARG" <karg@quipsy.de> wrote in news:49647771$1@forums-1-dub...
>> BTW, what is the difference between these newsgroups?
>>
>> "Volker Barth" <No_VBarth@Spam_GLOBAL-FINANZ.de> schrieb im Newsbeitrag
>
>> > At the moment I would suggest to repost your topic in the
>> > "sybase.public.sqlanywhere.general" NG and address the iAnywhere staff
>> > especially. IMHO the current NG "sybase.public.sqlanywhere" gets *much*
>> > lesser attention.
>
>


Markus KARG Posted on 2008-11-25 14:16:52.0Z
From: "Markus KARG" <karg@quipsy.de>
Newsgroups: sybase.public.sqlanywhere
References: <4912b7d9@forums-1-dub> <49194a20@forums-1-dub> <49196bc6$1@forums-1-dub> <491972ac@forums-1-dub> <491efc23@forums-1-dub> <491fc2d2$1@forums-1-dub>
Subject: Re: PROXY TABLE behaves different to BASE TABLE
Lines: 182
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.5512
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
X-RFC2646: Format=Flowed; Response
NNTP-Posting-Host: vip152.sybase.com
X-Original-NNTP-Posting-Host: vip152.sybase.com
Message-ID: <492c08d4@forums-1-dub>
Date: 25 Nov 2008 06:16:52 -0800
X-Trace: forums-1-dub 1227622612 10.22.241.152 (25 Nov 2008 06:16:52 -0800)
X-Original-Trace: 25 Nov 2008 06:16:52 -0800, vip152.sybase.com
X-Authenticated-User: panorama
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub sybase.public.sqlanywhere:228
Article PK: 866670

I did not say that I do not want help or suggestion by members. I just asked
Volker what I shall do with the stuff found in that log, since I am no log
files expert and don't know what to do if finding ANYTHING in the log. Also,
I did not say that Sybase is not allowed to jump in and answer my question;
I did not insist on solely users answering. BTW, in all the years with weird
Sybase problems, they never sent anybody here but mostly tried to work
around somehow. There was never *real* interesed by the supporters to
acutally solve an issue, but just to close it somehow.

BTW, you answered what I wanted to know: If it is a bug, I cannot do
anything, since Sybase will not solve the bug so soon that it is a real help
for me. And if it is not a bug, then I am as far as I am now. THAT was what
I wanted to say with "what shall it be good for?" since I am pretty
convinced that it is a bug, Sybase ALREADY KNOWS the problem (I already
talked to German support using paid incident case) and NO, they had NOT been
interested in solving it AND CLEARLY TOLD ME that they will close the bug as
soon as they found a WORKAROUND.

So my intention is to find the interest of Sybase members that want to FIX
it.

Regards
Markus

"Arthur Hefti" <arthur@catsoft.ch> schrieb im Newsbeitrag
news:491fc2d2$1@forums-1-dub...

> Markus
>
> what's the point in putting the question in the newsgroup if you don't
> want to try to find a solution based on suggestions of other members? Call
> Sybase and ask for support. They might even send somebody to your place
> who sets the suggested options and gives a look at the logs (depending on
> how much your willing to pay).
>
> Otherwise apply the cis_option and execute the query that makes the
> troubles. Check the server log or server window of the remote db. If the
> query is not the same, report it as bug to Sybase. If the query is the
> same, execute the query directly on the remote database and compare the
> results. Report a bug do Sybase if they differ.
>
> Arthur
>
>
> "Markus KARG" <karg@quipsy.de> wrote in message
> news:491efc23@forums-1-dub...
>> Volker,
>>
>> since what I execute is a simple "SELECT x, y FROM Table z WHERE y = ?" I
>> doubt that anything that I find in the log can be a help: What shall I do
>> if any fancy stuff is found in the log instead of the above SQL? I cannot
>> change it at all. So what shall it be good for, investing hours to check
>> the log? What do you expect to find there that I personally could change?
>>
>> Thanks
>> Markus
>>
>> "Volker Barth" <No_VBarth@Spam_GLOBAL-FINANZ.de> schrieb im Newsbeitrag
>> news:491972ac@forums-1-dub...
>>> Markus,
>>>
>>> AFAIK, the statement to the remote database will be shown there exactly.
>>> That could give you any hint if the OMNI layer might rewrite your
>>> statement
>>> to something unexpected. Though I'm not sure how parameter values are
>>> handled (and logged) in this respect. If they just appear as '?' then
>>> you
>>> won't get further hints whether they are passed unchanged. But then you
>>> might test with SELECT with a literal instead of parameters.
>>>
>>> In my humble experience, the CIS_OPTION has been quite helpful with
>>> proxy
>>> tables, e.g. to make sure that a statement is completely passed to the
>>> remote server instead of a slow interaction of local and remote data, or
>>> that a SELECT with a SQL function is really using this function on the
>>> remote side, too.
>>>
>>> Volker
>>>
>>> "Markus KARG" <karg@quipsy.de> wrote in news:49196bc6$1@forums-1-dub...
>>>> And what exactly shall I check for in that log?
>>>>
>>>> "Volker Barth" <No_VBarth@Spam_GLOBAL-FINANZ.de> schrieb im Newsbeitrag
>>>> news:49194a20@forums-1-dub...
>>>> > Markus,
>>>> >
>>>> > I can't comment whether there is a difference or not, but would
>>>> > suggest
>>>> > that
>>>> > you try to "debug" the remote connection with the help of cis_option:
>>>> >
>>>> > SET OPTION cis_option = 7;
>>>> >
>>>> > That may give you more insight as the server log (-o ....) will
>>>> > contain
>>>> > what
>>>> > statement exaclty the remote server has to execute.
>>>> >
>>>> > HTH
>>>> > Volker
>>>> >
>>>> >
>>>> > "Markus KARG" <karg@quipsy.de> wrote in news:4912b7d9@forums-1-dub...
>>>> >> Dear SA Community,
>>>> >>
>>>> >> today I'd like to report a very weird effect I just noticed in SA
>>>> >> 11.
>>>> >>
>>>> >> I am not yet able to reproduce it in a clean lab environment but
>>>> >> only
>>> in
>>>> > my
>>>> >> huge enterprise application, but there I can reproduce it absolutely
>>>> >> reliably.
>>>> >>
>>>> >> I noticed that sometimes a simple JDBC statement "SELECT pk, text
>>>> >> FROM
>>>> >> MyProxy WHERE text = ?" called with param1 set to "A" returns a
>>>> >> value
>>> of
>>>> >> B
>>>> >> for the same column, what is a paradoxon, since the query obviously
>>> must
>>>> >> return the same value that was provided as a parameter. The strange
>>> thing
>>>> >> is:
>>>> >>
>>>> >> * It works absolutely correct with BASE tables. The weird behaviour
>>>> > happens
>>>> >> only with PROXY tables and VIEWS on PROXY tables.
>>>> >> * It happens NOT in a standalone program but only inside of an
>>>> >> application
>>>> >> server (I assume that it will also happen inside of a standalone
>>> program
>>>> > as
>>>> >> soon as I find out the exact JDBC sequence used by the application
>>>> > server).
>>>> >> This is the reason why not reporting it as a bug so far. In fact, an
>>>> >> application server cannot be the reason as it works pretty well as
>>>> >> soon
>>>> >> as
>>>> > I
>>>> >> am using BASE tables, and JDBC doesn't have a feature that allows
>>>> >> the
>>>> >> application server to find out about whether it is a BASE or a PROXY
>>>> > table.
>>>> >> * It happens only if the WHERE-column is NOT the primary key (it
>>>> >> works
>>>> >> absolutely well if the WHERE-column is the primary key).
>>>> >> * It happens with pure random: The returned value is different at
>>>> >> each
>>>> > call
>>>> >> (but always an existing value of the queried column).
>>>> >>
>>>> >> I tried many times: Not changing the application or application
>>>> >> server,
>>>> > but
>>>> >> just replacing the PROXY by a BASE table (containing the exact same
>>>> > values!)
>>>> >> and vice versa. It is absolutely reproducible that BASE tables work
>>> well
>>>> >> while PROXY tables return pure random!
>>>> >>
>>>> >> Can anybody tell me why this will happen? Is that a bug or is it my
>>>> >> fault?
>>>> >> Any ideas?
>>>> >>
>>>> >> Thanks!
>>>> >> Markus
>>>> >>
>>>> >>
>>>> >
>>>> >
>>>>
>>>>
>>>
>>>
>>
>>
>
>