I was setting up a table for one of my CR10X's and the first time I realized I had not setup the dld file and association correctly. After fixing this I went back to LNDB and check the table __inlocs__ and all the correct columns were there now. When I hit apply it seems that evertything worked until I looked at the Status Messages and saw the following message:
Exception handled in BrokerMap_OnTableChanged, Index must be within the bounds of the List. Parameter name: index
All the other tables from my CR10X's and one CR1000 worked without error and automatically created the tables in my MySQL server. I'm not sure how to even go about fixing this as I've unselected it, hit apply and then tried again but still get the same message in Status Messages. The only thing I can come up with is to recreate the whole root object tree down to the CR10X that is causing the problem. I'd like to avoid that if possible since it is a lot of work and may not fix it.
Any ideas?
We are going to try to reproduce this here and get back with you on the best way to get things righted again.
If you do not mind, could email your datalogger program to support at campbellsci dot com, to my attention? It may be something in particular to the program... or not, but it is always good to have (and we'll be able to work with you directly, rather than via the forum).
Dana W.
I emailed you the following message and included the DLD program for the mentioned CR10X we are having an issue with.
We don't write the programs, we actually use Canary's software called MultiLogger and it generates the DLD file including the header information. We've used it for at least 5 years now and never had any issues with anything else and in fact we used it to program the other CR10X loggers that are working with LNDB just fine. Anyway, hope you can help me out or suggest something I can try.
Thanks
Hi,
I haven't seen your email yet, but we have tried to reproduce the issue here without success this morning. However, I do have something you could try, which we think will resolve the issue.
Open the LNDB Manager. On the Setup tab, clear the _inlocs_ check box for the station experiencing the problem.
Go to the Data Review tab, select the inlocs table, and archive it. Close LNDB.
In your support software, make sure the DLD file is associated with the datalogger. You can quickly check this by making sure that Input Location names rather than generic names (inloc1, inloc2) are associated when viewing the input locations (for instance, in LoggerNet's numeric monitor -- I think MultiLogger has something similar, though I haven't worked with it much).
Reopen LNDB, and on the Setup tab, re-enable the inlocs table.
This should recreate everything that is needed to collect the information from LoggerNet's data cache and store it in the database.
Normally, if you want to store data to a file or database from input locations, it's a good idea to write those back to a final storage location in the datalogger program (using P80), though I do recognize that this is likely not something MultiLogger supports.
I will pass your email on to someone else, since I am out of the office tomorrow and Friday, and I want to make sure we get this resolved.
Dana
Our Engineering team was able to identify a key problem in kumpfjn's program. It had duplicate names in the INLOCS table. This is what caused the problem. By modifying the program to have unique names for each INLOCS value and then following the reset steps given above, the problem was resolved.
Another suggestion that our engineers think might be relevant is to use Final Storage arrays instead of the INLOCS table when you want to save data that is ultimately intended
for LNDB (CR10X, CR23X, CR7, CR510). In a similar fashion, for newer loggers (CR1000/CR3000/CR800) it is preferred to use Final Storage tables over the Public table when LNDB is the target.
* Last updated by: GTProdMgr on 11/9/2012 @ 3:08 PM *