New customer database for DA

[Brian_Spooner]

Hi,

I thought I remembered reading somewhere that it was a best practice to open new customer databases every so often... We were thinking to do it once a year. My question though is what happens to the old customer databases? They still show up in the list to connect to in DA client. Can people go in and still use these or is there a way to have changes disabled for the old customer databases?

In EVBAAdmin I see there is an option to enable/disable "Customer background tasks" -- I'm not sure if that's the option I'm looking for or not.

Also, when the accessing an old "closed" database in DA - what are the limitations? Can you do NOTHING or could you still export if needed? If someone needs something from a search and it's closed, would they have to recreate their search in the new active database?

Thanks in advance for any clarification...

[Liam_Finn1]

Opening of new customer Databases is not always needed. It depends on the size of your searches and number of cases.

Some customers divide their customer databases by area of Law and others by year it depends on how you want to manage your environment. Others only have one database and stick with that.

If you create another customer database the old ones will remain and when you open the da client you will have a drop down box to choose which customer database you wish to connect to

Yes people can still go in and use the old databases. I dont believe there is a way to lock a Customer database to read only unless you create a group that has read only access and then move your users to the read only group which makes very little sense

If you managed to make the old customer databases read only somehow and they needed to do a search on the old case then you either grant them access again or they would have to create a new case and search in the new database

May i ask whats the reasoning behind wanting to make the old one read only. To export they need to have the ability to create exports

[Brian_Spooner]

Thank you very much for the information. I think we're leaning towards creating a new customer database every year or two. With all the cases we have it might make things more manageable.

The reason I wanted to see about making the old ones read only is for reporting & audit purposes. We have to audit & report on all searches being done in DA, daily. If I only had to report on cases in the new customer database, it would make things easier. If they can go back and do searches in all the old databases, now the report has to go check all those cases too.

I guess an option would be to make backup copies of the SQL database and then delete the old customer databases from EVBAAdmin - this way they don't even have a choice...just one active database for searches. Not sure how well that would go over though -- they may need to reference the old cases.

...or I could just stick with the one database :) You said it depends on size and # of searches -- how can I determine if I'm anywhere near the threshold?

[GertjanA]

Hello Brian,

Deleting db's in itself is an option, but what about upgrades? Customer db's are upgraded during an upgrade...

It should be possible to edit the configuration file for the client (if you're on V8) to prevent users from using a dropdown to select a customer...

http://www.symantec.com/docs/HOWTO31689

If you open the AcceleratorClient.exe.config file, you see somewhere at the bottom <appSettings> section.

In here, you can specify (for instance) the AcceleratorServer (da-server), Default Customer, and (for instance!) DisableChangeofCustomer. That would prevent users to change the customer in the client login screen.

This might help
 

[Liam_Finn1]

How are you reporting on the searches today?

Do you do it manually or have you written a SQL report to auto generate a report daily

[TonySterling · Accepted solution]

You can always edit the roles in the "closed" customer database to allow them to only export and not be able to create new cases or searches.  The later version of DA have greater granularity in role assignments.