I'm trying to update my push request table and only want the push table modified for the current person polling (my pollkey value is the ml username). I tried to use both {ml s.username} and ? to get the pollkey, but the first doesn't even let my listener run and the second doesn't seem to do anything.

Is there any way of getting the pollKey value in the Notifiers events? I'm using the light weight polling method, SQL Anywhere 12.0.1.

I believe you might have made a false assumption on how LWP and the Notifier works. The notifier events are not on the same line of execution of ML handling a sync. The Notifier has its' own line of execution in the embedded JVM of ML. The Notifier constantly monitor the consolidated database or external elements using the request_cursor and process pushes/confirmation etc. For LWP notifier, the push is simply to populate an in-memory bulletin board awaiting LWP clients to pull from it at their own pace without imposing consolidated db access nor authentification per such so called LWP access.

So, a LWP initiated by, say the listener (dblsn), will not invoke any Notifier event.

You can of course modify the content of your push request table in your ML synchronization events so that you can influence the request_cursor. This is infact the standard technique to implemt ACK for the LWP push. But this DML is not executed inside a Notifier event. The Notifier will query your push request table via your request_cursor at its' own line of execution (not in a ML sync).

To see what action variable is available to dblsn, you can simply run "dblsn -?". The variables are listed at the bottom of the usage text. $poll_key is listed.

Wait a minute.. I think while I was eating lunch I figured out what you were saying. So just to confirm.

The Notifier polls the database, using its request cursor and stores all the returned values in its own internal datatable or something. If my requestCursor grabs from my push request table and grabs all the values where status = 'sync', it will possibly return 5 results.

My listener polls the notifier, which looks in its own internal datatable (which has 5 results) and compares the listeners pollKey with the first column (which is why the help says the requestCursor select statement must return PollKey, Subject, Content in that order). And then the notifier returns only the pollKey, subject, content to the listener if it found a match.

It might be too extreme to say the notifier should only passively grab data. There are other notifier events along the line of the notifier execution that one can use to compute and create pushes that is going to be selected by the request_cursor. One can also use a complex query against existing tables for the request_cursor without having the need of creating a push request table, insert into it and later having the request_cursor to plainly select from it. The notifier is not limited to be passive.