Hi Cyprian,

I'm not sure if the ability to select alternative SQL Server databases via the front end is a general requirement but if it is then this could certainly be considered.  As to the other questions, SQL Server, MSDE and SQL Server Express/2005 all work the same way, that is, they indeed process the query on the server and return just the results set to the client.  As you say, this contrasts with Access where the entire data is returned to the client machine for processing.

In my experience, Access can perform quite well in comparison with SQL Server but only when there is only a small amount of data, with the data on the same machine as the client application (as in a Recorder Standalone install) and when there are very few concurrent users (i.e. rarely more than 1).  As soon as you move the data onto a network, increase the volume of data, or increase the number of users the performance advantages of client/server become very apparent.  Furthermore, SQL Server has a much 'richer' server programming language allowing complex code to be run on the server itself, further improving performance.  A caveat to this is that when considering a Recorder 6 (or any other SQL Server installation) it is important to put the database on a reasonably quick machine.  The client machine isn't so important as it doesn't process the queries.

Finally, apart from dictionary updates, the Recorder 6.8 upgrade includes the following:
1) Ability for JNCC to issue dictionary updates separately to the application updates.
2) Making the standalone and network install kits compatible with SQL Server Express/2005 (only if you have an existing instance).
3) Enhancements to the way the Import Wizard imports locations and determinations
4) Some nice new facilities for exporting the results set of a report to a variety of formats.
5) Significant performance enhancements to the Taxon Dictionary.

Best Wishes,

An addition to the addition - if you switch databases in this way, you should also switch your Object Sheet Path and Map File Path registry settings so that the folder used is unique for each database.  Otherwise you'll have to keep resetting your maps when you switch.

No, its not used anymore in Recorder 6.  For SQL Server access, it uses ADO directly and for Access (only used in the import process) it also uses ADO and Jet.  However, there are still parts of Recorder 6 where the SQL code has never been re-optimised for SQL Server (we use a translator to make sure the SQL at least runs) but we are gradually updating to optimised SQL as work is done on each part of the system.

MSDE only runs on Windows, as far as I am aware. When it refers to Win2K, it means either the server or the desktop editions - it doesn't matter which.

Just to clarify matters, MSDE (Microsoft SQL Server Desktop Engine) is, essentially, a cut-down version of the full SQL Server 2000 software. Also, the difference between a database server and a file server is really all about how they're configured and what software they have installed on them, rather than them being intrinsically different beasts. In other words, a file server that you install MSDE or SQL Server onto so becomes a database server as well as a file server.

Hope that helps!

We currently run our SQL Server 2005 install on our mirror backup server (It's a 3GHz single Xeon Dell PowerEdge). The server pretty much idles there the whole time doing nothing, just copying files from the main server occassionally, so we thought we'd make better use of its resources and get Recorder on there. It been a very satisfactory arrangement so far, especially since we upgraded it to 3GB of RAM. Even with Recorder on there, it still sits there idling most of the time as even with the potential for 7 concurrent users, only one person ever seems to be using it at one time.

A couple of points woth noting from all of this:

1) one of the biggest advantage we have found in putting our Recorder db onto a seperate server is ease of maintenance. The server is more simple overall, so less complexity means there is less to go wrong and generally makes it much easier to maintain.

2) Even though the server idles for roughly 95% of the time (at a guess), those big Recorder reports can really tie it up for the other 5% of the time. When we had Recorder on our general purpose server, other people within the organisation would notice and start complaining when we were running large reports. Now that Recorder is on a semi-dedicated server, we only have to worry about slowing down other Recorder users.

Cyprian,

What volume of data are you storing in each of the databases?

It sounds like you will have a million or a bit more records.  Recorder 6 should have no significant problems coping with this amount of data in a single dataset.

This is one of those features that I'd like to see go on the wishlist - the categorisation of surveys within Recorder so that sets of surveys can be grouped together in some sort of hierarchical folder-like structure. This would then make it not only very easy to keep distinct sets of data seperate from each other, but would also allow us to combine them just as easily. The ability to 'fence-off' certain sets of data is become increasingly important for us. For instance, there is an increase in the number of cross-county-border enquiries we need to do. This requires obtaining records from other centres, so we'd like to be able put other counties' data into their own folders.

Regarding the reporting side of things, now that we have the taxon group information in Recorder, the ability to filter on a particular group would come in very handy, although it's easy enough to do using XML Reports. Are you able, or do you have anyone able, to write SQL queries for you Cyprian? Having these skills in-house, or available on tap really opens up endless possibilities.

Gordon or Charles, would either of you like to submit the above in the "feature request" thread?

from what I understood -I could be wrong- if you only have R6 &  SQL on the server then it is best to have everything on the one box, but if the server is also acting as a non R6 file server for use then it is best to seperate SQL.

Hi and thanks for the prompt replies. 

On Friday I moved the Rec6 install again so now the SQL and the program files are back on a completely dedicated server again. 

After some testing I notice processing speed has increased again.  I'm thinking the server i'd placed the program files on is just too over used and to have everything on this one dedicated server is by far the better option for now. 

Thankfully i've got Rec6 installation here down to 1hour so it hasnt been too much hassle. 

Thanks again for the info and advice,
Catherine

I too would appreciate any information users can provide in this area - to help with the improvement of the network installation guide.

Would it be possible for you to copy me in on anything you can send?

Many many thanks,

Sarah

Sarah Shaw
Biodiversity Information Assistant
JNCC