I am looking at using the CsiDatasource control and an advisor to get the latest records by setting the startdate and the startoption of the advisor.

When i call start of the advisor it will return me the latest records, how do i know that i have got them all? Is there are property of one of the other objects that can tell me that i have got all the latest records? or how many records to expect?

[Report Inappropriate or Erroneous Content]

There is no explicit property on the Advisor that signifies "caught up", but you could use the "newest record" from an independent source to confirm that the proper records have been received.

There are two common use cases in which an SDK app might use an Advisor. In one mode, the Advisor is used to continually "watch" and "listen to" LoggerNet, and receives a notification anytime records are received in LoggerNet's "cache" from the datalogger (those records arrive at LoggerNet as a response to a scheduled collection event or a "collect now" event).

In that case, the Advisor is initially configured, then immediately collects a set of records from Loggernet to get "caught up" to the current moment (latest record) and then it waits. Then whenever LoggerNet gets records, the Advisor gets notified and records are sent across to the SDK app.
(onAdviseRecord event or onAdviseRecords event)

In the other use case, the Advisor is used only temporarily to collect records from LoggerNet with a "one time" interaction. One query is made to LN's cache, and one set of records are returned as the response, and then the Advisor object is shut down.

If you are using the Advisor in the "long-term listen" mode, then it usually has the newest record already. There is an "initial query" of records that come across right when the Advisor is set up, but after the advisor catches up on that, then it typically keeps caught up because it receives the new records right when LoggerNet gets them. It does take a short time for the records to be transferred, but for most applications (with 1 second or longer data intervals) that doesn't become a significant factor.

It would be possible to create a separate Advisor to look at the "newest record only" for a table and compare it to what the long term advisor has. Most users wouldn't find that necessary. You usually just set up the advisor, let it catch up to the current record, and then use a Numeric monitor in loggernet to confirm that the newest record LoggerNet reports is a "match" with the newest record in the SDK app.

Also, you usually want to watch the SDK app a few times when a "scheduled collection" or "collect now" event occurs, to make sure the records are sent over properly.

If you are doing a one-time query, then you simply could compare the newest record received in the query (if it is the newest that LN has) with a Numeric monitor in LoggerNet to confirm that you got the record with the newest timestamp.

I hope this helps.

You may want to review Section 18 of the SDK manual:
http://www.campbellsci.com/documents/manuals/loggernet-server-sdk.pdf

[Report Inappropriate or Erroneous Content]

"In the other use case, the Advisor is used only temporarily to collect records from LoggerNet with a "one time" interaction. One query is made to LN's cache, and one set of records are returned as the response, and then the Advisor object is shut down."

You say in the above that doing this would return a set of records. So does that mean it would fire the on OnAdviseRecords event not the OnAdviseRecord?

[Report Inappropriate or Erroneous Content]

Per Section 18.1.3 (page 18-11) you use the "sendRecordBlocks" property to control whether "onAdviseRecord" is the triggered event, or "onAdviseRecords" at the time records are sent to the advisor.

With sendRecordBlocks set to false, the onAdviseRecord
event will be triggered as each individual record arrives to the Advisor. When sendRecordBlocks is set to true, then multiple records can arrive at once and those can be processed with a single triggering of onAdviseRecords.

It may still take more than one firing of onAdviseRecords for the full response of records to be returned to the Advisor.

Consider the case where a query is made that results in 500 records needing to be sent to the Advisor.

If sendRecordBlocks=false, then you will see onAdviseRecord trigger 500 individual times.

If sendRecordBlocks=true, you might see onAdviseRecords trigger 10 times, containing 50 records each time it triggers. How many records make it across for a single onAdviseRecords event depends on multiple factors, including baudrate or throughput and packet size. It isn't easy to predict, so you should write your code to handle multiple triggerings of the onAdviseRecords event.

http://www.campbellsci.com/documents/manuals/loggernet-server-sdk.pdf

[Report Inappropriate or Erroneous Content]

because we aren't using scheduled polling i am looking at firing a manual-poll using the CsiCoraScript.

Then i can either use
- Firstly create an advisor to give me the latest record, then i can store the recordid away and create another advisor using a startdate then as each records comes in check whether it matches the id that was returned when we asked for the newest record.

or

- CsiCoraScript to fire a data-query command

I guess the first one would be better, considering you don't know how many records may be returned(using the sendRecordBlocks=true)?

One other thing, with sendRecordBlocks=true, if you have blocks of 50 and there are 501 records waiting, the last record still comes in on the OnAdivseRecords not OnAdviseRecord?

* Last updated by: Hilltop on 9/1/2011 @ 4:22 PM *

[Report Inappropriate or Erroneous Content]

As has already been mentioned, the data advise transaction is meant to provide a means of efficiently monitoring a continuous data feed. Since you are already using the corascript control. One of the commands that may be of interest is the table-data-index command. This command can be used to get an overview of the data that is currently stored in the cache table. Using this, you could use the following sequence:

manual-poll logger;
table-data-index logger table;

You can then use the information given in the returned list, specifically the last end record number and/or time stamp to determine when all of the data that was collected has been pumped through the data advise transaction.

[Report Inappropriate or Erroneous Content]

I executed that command and got the following.

*table-data-index,"teachers college","data_test"
{
{5 1703 2698 {2011-08-31 09:32:45} {2011-08-31 13:41:30}}
{6 12197 13200 {2011-09-02 05:16:15} {2011-09-02 09:27:00}}
}
+table-data-index

So with this returning two records, would I then use the 13200?

* Last updated by: Hilltop on 9/1/2011 @ 6:20 PM *

[Report Inappropriate or Erroneous Content]

Larger file-mark numbers usually correspond to newer records. This case is pretty clear cut -- filemark 6 has larger record numbers and newer timestamps. So the newest record that loggernet has in its cache has a record number of 13,200
and a timestamp of 2011-09-02 09:27:00. When your advisor gets to that record then it should be "done".

(This assumes the "manual-poll" method so that no polls or scheduled polls have occurred between the table-data-index execution and the completion of the advisors onAdviseRecord(s) events.)

[Report Inappropriate or Erroneous Content]