Topic: Recorder 6 Final

I've just had a call from John Morris at JNCC to inform me that he's sending out the final version (I suppose it's a release candidate) of Recorder 6 to a select few organisations for final testing. If you would like a copy, send him an email on [email protected].

Charles

2

Re: Recorder 6 Final

charlesr wrote:

I've just had a call from John Morris at JNCC to inform me that he's sending out the final version (I suppose it's a release candidate) of Recorder 6 to a select few organisations for final testing. If you would like a copy, send him an email on [email protected].

Charles

Thanks for this Charles. I've emailed to ask for a copy.

Re: Recorder 6 Final

There are two versions, by the way; one for standalone installs and one for a server install. Make sure you specify which you'd like, or both, if necessary.

Charles

Re: Recorder 6 Final

Recorder 6 looks like it will be very useful to GIGL, particularly for the enhanced reporting capability. However, I am relectant to install it if its still full of bugs. Can anyone advise how stable this 'final' version is?

Matt

Re: Recorder 6 Final

First thing you should know is that you don't have to install it over Recorder 2002, they install alongside each other nicely. This means you can install R6, tranfer your data and test it out for as long as you like, with Recorder 2002 still running as your live db. Only limitation is that you can't open them up both at the same time.

Second is that R6 appears from my testing to have less bugs that Recorder 2002, or, at least, that seems to be the case with the version I've been testing . It seems a lot more stable and capable. I'll post more when I've had a chance to install this final version.

Charles

6

Re: Recorder 6 Final

charlesr wrote:

First thing you should know is that you don't have to install it over Recorder 2002, they install alongside each other nicely. This means you can install R6, tranfer your data and test it out for as long as you like, with Recorder 2002 still running as your live db. Only limitation is that you can't open them up both at the same time.

Second is that R6 appears from my testing to have less bugs that Recorder 2002, or, at least, that seems to be the case with the version I've been testing . It seems a lot more stable and capable. I'll post more when I've had a chance to install this final version.

Charles

The dual install is useful to know. Is everything seperate on a network install too, e.g. will the recorder client live in a different place in the registry?

Re: Recorder 6 Final

davec wrote:

The dual install is useful to know. Is everything seperate on a network install too, e.g. will the recorder client live in a different place in the registry?

I don't know about the network install as I've not tried it yet, but Recorder 6 does create its own registry entries. One thing to beware of: I noticed some add-in strangeness when I installed R6. It seemed to take-over R2K2's add-ins, putting them into R6 and removing them from R2K2. This was easily solved by reinstalling them in R2K2 (just install the .ocx files found in the R2K2 addins directory), which subsequently disabled them in R6. So it looks like the add-ins registration is shared between the two.

Charles

Re: Recorder 6 Final

The network version will not be made available for a few weeks apparently. Also JNCC will direct you to resellers only.

Tony Price
Data Manager, Somerset Environmental Records Centre (SERC)

9

Re: Recorder 6 Final

TonyPrice wrote:

The network version will not be made available for a few weeks apparently. Also JNCC will direct you to resellers only.

I've got the Network version now. I'd like to use a clean machine first.

10

Re: Recorder 6 Final

This is a quick post to say I have had a chance to carry out a test install the Recorder 6 network version. The install is easy enough, but the installation manual is a bit unstructured although it does contain detailed technical notes. The "getting started" menu on the installer opens Recorder 2000/2 documentation. I am using the MSDE database server which is included within the install.

Data migration is not permitted across a network drive so I had to copy the contents of the Recorder 2002 database folder to the local machine hosting Recorder 6. The installer can then use this local copy. The time required for data migration depends on the size of your data, of course, and the speed of your PC. Our 500,000+ database took over three hours on a modest PC used for this test. (700Mhz CPU, 96MB Ram, Windows 2000 Professional).

When migration is under way a progress bar indicates the temporal status with textural information providing the number of records that have been transferred or are in error.

Once installation is complete, the Recorder 6 directory contains a setup program to install the client (workstation) frontend program. I started by mapping the Recorder 6 install directory (C:\Program Files\Recorder 6 Server\) as a network share with user read/write permissions. Then, back at a desktop PC, I opened this mapped folder and then opened the "Workstationsetup.exe" installer. This places a small (approx. 5MB) distribution into the program files directory and a shortcut back to "Recorder.exe" in the network folder.

Note that if you have Recorder 2002 on the same desktop PC as you install Recorder 6 workstation, you will loose the add-ins. These get overwritten by the workstation install but you can reinstall them into Recorder 2002 afterwards. This may be a Windows Registry issue. Registry settings for Recorder 6 are documented in the Dorset Software install manual. I can't supply a page reference as all the pages are number three! After the main workstation install dialog has completed there is a further install of components by a second installer. That installer took a while to open.

Opening Recorder 6 provides a user inteface based on Recorder 2002, so users should feel comfortable with existing skills.

Re: Recorder 6 Final

Great post, Dave, thanks. If you notice any problems, bugs or errors, there's a deadline of 21 October to get your incident reports into Hannah by.

Charles

Re: Recorder 6 Final

Anyone else not getting the NBN Gateway links working?

Rob Bradley
Edinburgh

Re: Recorder 6 Final

Yeah, they don't work. Are you able to run a query against the database (see here for free tools)? If so I have some SQL to correct it. If you're happy running SQL against the db, let me know and I'll post here.

Charles

Re: Recorder 6 Final

Cheers for that Charles, but it's mainly for demo purposes just now... had a little red-faced incident the other day...The current workplan will roll out R6 during next year. I take it there is an intention to fix this at some time?

Rob Bradley
Edinburgh

Re: Recorder 6 Final

I've reported it to Hannah, so I would imagine so. To fix it you simply need to change one value in the SETTINGS table in the database. If you're able to get in there and change the GatewayeURL value to:

http://www.searchnbn.net/searchengine/s … earchTerm=

you should be all set.

Charles

Re: Recorder 6 Final

We're looking at doing a clean install in the next 10 days & have a few wee queries. Our HQ will be networked using a 2003 Server whilst putting in standalone machines throughout the Reserves.

Our current catalogue has 350k records in it which I anticipate rising to about 500k by the end of the year. What size of database will this occupy on server?

To streamline our paper filing system,  we're going to implement splitting species records folders into 5 areas: Invertebrates, Birds, Mammals (including ampibians & reptiles), botanicals and site visits. How do folk think about organising the observation hierarchy to reflect these & then slotting in surveys accordingly?

Similarly will be organising locations by Reserve, with sub-locations of compartemnts etc using existing .gsf files from ArcView. Any thoughts?

Finally, to look to the future, where we anticipate a network of volunteer & seasonal staff updating Reserve-based datasets, will the degree of network performance be an issue?

Cheers now, Rob

Rob Bradley
Edinburgh

Re: Recorder 6 Final

Rob.Bradley wrote:

Our current catalogue has 350k records in it which I anticipate rising to about 500k by the end of the year. What size of database will this occupy on server?

We have just over 900K records and our database is occupying around 1.7GB. This fluctuates, though, and I've seen it go over 2GB. Either way, with hard disks being the size they are these days, I'm guessing storage capacity (or lack of) shouldn't be to be a problem.

Rob.Bradley wrote:

To streamline our paper filing system,  we're going to implement splitting species records folders into 5 areas: Invertebrates, Birds, Mammals (including ampibians & reptiles), botanicals and site visits. How do folk think about organising the observation hierarchy to reflect these & then slotting in surveys accordingly?

If you're receiving records from other Recorder users, then it's difficult to keep a survey based filing system as they will use whatever methods they stumble across via the poor Recorder documentation. You have the opportinuty to publish some guidelines and export your survey, location and individual structures out to people before they create their own. If your records logically fall into these categories and are physically filed that way then it makes sense to file them in Recorder that way too.

We don't have that luxury and so we go by the following rules: ad-hoc records coming in on a day-to-day basis go into quarterly surveys, i.e. we have one survey per quarter. If the records are the product of a formal survey or some recording activity that can be logically classed as a survey, with accompanying metadata, then we create a distinct survey.

Rob.Bradley wrote:

Similarly will be organising locations by Reserve, with sub-locations of compartemnts etc using existing .gsf files from ArcView. Any thoughts?

Sounds like a good way to go. Recorder has excellent site/location recording capabilities (it's often overlooked as 'just' a species recording package) and is an very good solution for holding site data.

Rob.Bradley wrote:

Finally, to look to the future, where we anticipate a network of volunteer & seasonal staff updating Reserve-based datasets, will the degree of network performance be an issue?

Server performance will be an issue, but network traffic is fairly light. Ensure you have very powerful processor and lots of RAM. I recommend 2GB of RAM and, if you have a lots of people accessing the database regularly doing reports or importing while others are doing data entry, then I'd highly recommend dual processors.

Charles