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.

tables updated over the internet.

5 posts in Internet Server Last posting was on 2007-02-08 14:00:58.0Z
Jim Gabriel Posted on 2007-01-27 01:42:19.0Z
From: "Jim Gabriel" <nospam@gmail.com>
Newsgroups: Advantage.Internet_Server
Subject: tables updated over the internet.
Date: Fri, 26 Jan 2007 17:42:19 -0800
Lines: 17
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
NNTP-Posting-Host: 71.104.97.66
Message-ID: <45baacfb@solutions.advantagedatabase.com>
X-Trace: 26 Jan 2007 18:38:03 -0700, 71.104.97.66
Path: solutions.advantagedatabase.com!solutions.advantagedatabase.com!71.104.97.66
Xref: solutions.advantagedatabase.com Advantage.Internet_Server:716
Article PK: 1120978

I tried using a trigger that creates a UDP connection to notify client apps
when a table had changed. This worked fine in an local area network
environment, but fails when connections are made over the internet. UPD
connections are almost useless getting through routers.

So, I now use a TCP connection instead. It is a bit more work but really is
the only way I can figure out how to get that to work properly over a local
area network and internet.

Would ANYONE find this information on how I did this? It seems like nobody
is concerned with knowing WHEN a table has been updated over the internet
and the client application dataset needs to be refreshed.


Jim


Paul Man Posted on 2007-02-06 11:49:41.0Z
From: "Paul Man" <paulman@datasoft.ie>
Newsgroups: Advantage.Internet_Server
References: <45baacfb@solutions.advantagedatabase.com>
Subject: Re: tables updated over the internet.
Date: Tue, 6 Feb 2007 11:49:41 -0000
Lines: 35
Organization: DSoft
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
X-RFC2646: Format=Flowed; Response
NNTP-Posting-Host: 82.141.233.142
Message-ID: <45c86a81@solutions.advantagedatabase.com>
X-Trace: 6 Feb 2007 04:46:09 -0700, 82.141.233.142
Path: solutions.advantagedatabase.com!solutions.advantagedatabase.com!82.141.233.142
Xref: solutions.advantagedatabase.com Advantage.Internet_Server:717
Article PK: 1120979

I'd create a tcp/ip server application and get the clients to connect into
that rather than attempting to connect out from the server trigger.
Then you can use your original udp code to inform that app server of
changes. Your clients then could connect into the app server and regularly
check for updates.

If you were attempting to create outgoing tcp/ip connections directly from
the server then this will impact the trigger time due to any failed or
delayed connections - hence the trigger should just fire the UDP
notification to the app server. Your clients then could interrogate the
app server directly on a timer basis for update notifications.

The other method I use is for lookups where I use a rowversion field and
query the maximum rowversion for changed records.

"Jim Gabriel" <nospam@gmail.com> wrote in message
news:45baacfb@solutions.advantagedatabase.com...
>I tried using a trigger that creates a UDP connection to notify client apps
>when a table had changed. This worked fine in an local area network
>environment, but fails when connections are made over the internet. UPD
>connections are almost useless getting through routers.
>
> So, I now use a TCP connection instead. It is a bit more work but really
> is the only way I can figure out how to get that to work properly over a
> local area network and internet.
>
> Would ANYONE find this information on how I did this? It seems like nobody
> is concerned with knowing WHEN a table has been updated over the internet
> and the client application dataset needs to be refreshed.
>
>
> Jim
>


Jim Gabriel Posted on 2007-02-06 18:11:58.0Z
From: "Jim Gabriel" <nospam@gmail.com>
Newsgroups: Advantage.Internet_Server
References: <45baacfb@solutions.advantagedatabase.com> <45c86a81@solutions.advantagedatabase.com>
Subject: Re: tables updated over the internet.
Date: Tue, 6 Feb 2007 10:11:58 -0800
Lines: 54
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
X-RFC2646: Format=Flowed; Response
NNTP-Posting-Host: 71.104.97.66
Message-ID: <45c8c3e9@solutions.advantagedatabase.com>
X-Trace: 6 Feb 2007 11:07:37 -0700, 71.104.97.66
Path: solutions.advantagedatabase.com!solutions.advantagedatabase.com!71.104.97.66
Xref: solutions.advantagedatabase.com Advantage.Internet_Server:719
Article PK: 1120980

In re-reading your method, I realized my implementation is just slightly
different.

1) I have the app server broadcast to the clients connected to the specific
alias the specific table that has changed.
2) The clients apps only poll their local listening object to see if server
app had sent them anything. I don't have the client poll the server
directly.

I, too, found the the TCP connection I had from the trigger to the app
server was slowing the trigger performance down significantly. UDP was the
way to go.

Jim

"Paul Man" <paulman@datasoft.ie> wrote in message
news:45c86a81@solutions.advantagedatabase.com...
> I'd create a tcp/ip server application and get the clients to connect into
> that rather than attempting to connect out from the server trigger.
> Then you can use your original udp code to inform that app server of
> changes. Your clients then could connect into the app server and
> regularly check for updates.
>
> If you were attempting to create outgoing tcp/ip connections directly from
> the server then this will impact the trigger time due to any failed or
> delayed connections - hence the trigger should just fire the UDP
> notification to the app server. Your clients then could interrogate the
> app server directly on a timer basis for update notifications.
>
> The other method I use is for lookups where I use a rowversion field and
> query the maximum rowversion for changed records.
>
> "Jim Gabriel" <nospam@gmail.com> wrote in message
> news:45baacfb@solutions.advantagedatabase.com...
>>I tried using a trigger that creates a UDP connection to notify client
>>apps when a table had changed. This worked fine in an local area network
>>environment, but fails when connections are made over the internet. UPD
>>connections are almost useless getting through routers.
>>
>> So, I now use a TCP connection instead. It is a bit more work but really
>> is the only way I can figure out how to get that to work properly over a
>> local area network and internet.
>>
>> Would ANYONE find this information on how I did this? It seems like
>> nobody is concerned with knowing WHEN a table has been updated over the
>> internet and the client application dataset needs to be refreshed.
>>
>>
>> Jim
>>
>
>


Paul Man Posted on 2007-02-08 14:00:58.0Z
From: "Paul Man" <paulman@datasoft.ie>
Newsgroups: Advantage.Internet_Server
References: <45baacfb@solutions.advantagedatabase.com> <45c86a81@solutions.advantagedatabase.com> <45c8c3e9@solutions.advantagedatabase.com>
Subject: Re: tables updated over the internet.
Date: Thu, 8 Feb 2007 14:00:58 -0000
Lines: 79
Organization: DSoft
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
NNTP-Posting-Host: 82.141.233.142
Message-ID: <45cb2c45@solutions.advantagedatabase.com>
X-Trace: 8 Feb 2007 06:57:25 -0700, 82.141.233.142
Path: solutions.advantagedatabase.com!solutions.advantagedatabase.com!82.141.233.142
Xref: solutions.advantagedatabase.com Advantage.Internet_Server:721
Article PK: 1120983

The only issue with using UDP is that you might want to build in an
expectation of getting a reply back from the appserver that it has received
the notification. Otherwise it is possible to issue a udp that is not
received by the server app given the limitiaitons of udp. If the app
doesnt send back a udp notification of receipt then you can retry again
after a few seconds. This of course means that your trigger has to create
data module or form that stays in the background processing these receipts.

Alternatively the appserver could update a status table in your database to
show that it has received the notification.

However I found that using a rowversion field in my tables to be sufficient.
Every time the record gets inserted/updated the rowversion changes to a new
incremental value. My clients periodically query the max(rowVersionfield)
to see if it is > than the previous maximum value. If so then they select
all those records between to earlier maximum value and the current and that
give the updated list of changed records.

"Jim Gabriel" <nospam@gmail.com> wrote in message
news:45c8c3e9@solutions.advantagedatabase.com...
> In re-reading your method, I realized my implementation is just slightly
> different.
>
> 1) I have the app server broadcast to the clients connected to the
> specific alias the specific table that has changed.
> 2) The clients apps only poll their local listening object to see if
> server app had sent them anything. I don't have the client poll the
> server directly.
>
> I, too, found the the TCP connection I had from the trigger to the app
> server was slowing the trigger performance down significantly. UDP was
> the way to go.
>
> Jim
>
> "Paul Man" <paulman@datasoft.ie> wrote in message
> news:45c86a81@solutions.advantagedatabase.com...
>> I'd create a tcp/ip server application and get the clients to connect
>> into that rather than attempting to connect out from the server trigger.
>> Then you can use your original udp code to inform that app server of
>> changes. Your clients then could connect into the app server and
>> regularly check for updates.
>>
>> If you were attempting to create outgoing tcp/ip connections directly
>> from the server then this will impact the trigger time due to any failed
>> or delayed connections - hence the trigger should just fire the UDP
>> notification to the app server. Your clients then could interrogate the
>> app server directly on a timer basis for update notifications.
>>
>> The other method I use is for lookups where I use a rowversion field and
>> query the maximum rowversion for changed records.
>>
>> "Jim Gabriel" <nospam@gmail.com> wrote in message
>> news:45baacfb@solutions.advantagedatabase.com...
>>>I tried using a trigger that creates a UDP connection to notify client
>>>apps when a table had changed. This worked fine in an local area network
>>>environment, but fails when connections are made over the internet. UPD
>>>connections are almost useless getting through routers.
>>>
>>> So, I now use a TCP connection instead. It is a bit more work but
>>> really is the only way I can figure out how to get that to work properly
>>> over a local area network and internet.
>>>
>>> Would ANYONE find this information on how I did this? It seems like
>>> nobody is concerned with knowing WHEN a table has been updated over the
>>> internet and the client application dataset needs to be refreshed.
>>>
>>>
>>> Jim
>>>
>>
>>
>
>


Jim Gabriel Posted on 2007-02-06 17:58:38.0Z
From: "Jim Gabriel" <nospam@gmail.com>
Newsgroups: Advantage.Internet_Server
References: <45baacfb@solutions.advantagedatabase.com> <45c86a81@solutions.advantagedatabase.com>
Subject: Re: tables updated over the internet.
Date: Tue, 6 Feb 2007 09:58:38 -0800
Lines: 60
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
X-RFC2646: Format=Flowed; Response
NNTP-Posting-Host: 71.104.97.66
Message-ID: <45c8c0c9@solutions.advantagedatabase.com>
X-Trace: 6 Feb 2007 10:54:17 -0700, 71.104.97.66
Path: solutions.advantagedatabase.com!solutions.advantagedatabase.com!71.104.97.66
Xref: solutions.advantagedatabase.com Advantage.Internet_Server:718
Article PK: 1120981

This is exactly what I implemented. The trigger communicates to a app
server via UDP, and the app server ultimately communicates with the client
apps via TCP of the table changes.

The app server runs as a service and I display the current connections
(alias/username/IP) in a list box. I can send messages to ALL or selective
connections that will display a modalles 'alert' dialog in the lower right
hand corner of screen; similar to Yahoo's IM when a new mail message
appears. This is cool to alert users of system issues or lauch a two way
messaging dialog.

I'm not familiar with the method you use for lookups for a rowversion field
and query the maximum rowversion for changed records. Can you elaborate?

This is the kind of design discussions that I crave for.

Thanks
Jim

"Paul Man" <paulman@datasoft.ie> wrote in message
news:45c86a81@solutions.advantagedatabase.com...
> I'd create a tcp/ip server application and get the clients to connect into
> that rather than attempting to connect out from the server trigger.
> Then you can use your original udp code to inform that app server of
> changes. Your clients then could connect into the app server and
> regularly check for updates.
>
> If you were attempting to create outgoing tcp/ip connections directly from
> the server then this will impact the trigger time due to any failed or
> delayed connections - hence the trigger should just fire the UDP
> notification to the app server. Your clients then could interrogate the
> app server directly on a timer basis for update notifications.
>
> The other method I use is for lookups where I use a rowversion field and
> query the maximum rowversion for changed records.
>
> "Jim Gabriel" <nospam@gmail.com> wrote in message
> news:45baacfb@solutions.advantagedatabase.com...
>>I tried using a trigger that creates a UDP connection to notify client
>>apps when a table had changed. This worked fine in an local area network
>>environment, but fails when connections are made over the internet. UPD
>>connections are almost useless getting through routers.
>>
>> So, I now use a TCP connection instead. It is a bit more work but really
>> is the only way I can figure out how to get that to work properly over a
>> local area network and internet.
>>
>> Would ANYONE find this information on how I did this? It seems like
>> nobody is concerned with knowing WHEN a table has been updated over the
>> internet and the client application dataset needs to be refreshed.
>>
>>
>> Jim
>>
>
>