WorkSite databases – where and wherefore

WorkSite databases – where and wherefore

iManage WorkSite has a client-and-many-server application architecture. The profile records, structure, and metadata are stored in a relational database – SQL Server or Oracle. The content itself is stored on a file server – which can be encrypted to be HIPAA-compliant as of WorkSite 9.0.  The client machines – running FileSite or DeskSite – never communicate directly with the database server. All communication is brokered directly through the WorkSite server. So, in theory, that database could be renamed at some levels and relocated to a new server: the end-users would have no way of knowing, and no reason to care.

The naming of the database is completely ‘up to you’ – it’s determined at installation and configuration time.  You can give it one name on the relational database server, like “WorkSite”, so that you can distinguish it easily from other applications’ databases.  This name is not visible to the users of the system, but it is certainly vital to the server configuration.

Read further for where the name is configured…

What’s in a database name?

The name users see is largely/completely determined by the name of the ODBC system data source created on the WorkSite server(s). That is the source of the name people see in the FileSite navigation pane in Outlook. I like to use a name that reflects the purpose of the content. Perhaps Legal (or Legal1 if you are planning for growth). Or Admin. Or, Active if you are planning ahead to the Active-Archive content lifecycle. So, to build on the earlier example, the SQL database is called “WorkSite” and the ODBC datasource and functional name is “Legal1”.

Next, the iManage dbAdmin tool has a table of metadata called ‘database’.  This is used to populate the ‘preferred database’ setting on each user record. While this table may appear to be decorative in that no visible errors occur when it’s empty, substantial strangeness can result when users do not have consistent preferred database settings across multiple databases. Therefore, populate this table manually when you configure WorkSite. Make sure the database names are consistent with those ODBC names, on all of your WorkSite servers and in all of your SQL databases.

Does this satisfy your curiosity? Contact me for a quick chat or email discussion if you’d like to know more.  Cersys can coach your department to become WorkSite gurus.

9 thoughts on “WorkSite databases – where and wherefore”

  • No, I didn’t mean to give the impression that you should try to keep WorkSite separate.

    Actually the opposite. Instances support separate SQL versions without requiring a separate db server – virtual or physical. I like the idea that you only administer the one server, assuming it gives the right performance.

    For example, a very small firm might be running WorkSite 8.2 on SQL Server 2005, but their case management software requires an upgrade to SQL Server 2008. By setting up a 2005 instance for WorkSite and a 2008 instance for the Case Management, they can continue to have only the one SQL Server… and they are not forced simultaneously to upgrade to WorkSite 8.5 just to remain on only-one-database-version.

    Instances are not ‘magic’ – they do require more memory from the system than a plain old additional database. I’ll only tell our example small firm to use a separate instance if it’s explicitly required to be separated from the other application for version or upgrade reasons. Until that time, the two databases can live side by side in the same instance on one server.

    • Ah fantastic I was hoping that was what you meant. I will add the job “move WorkSite databse back into our backend SQL server” along with our myriad other clean-up jobs!

      Now onto planning our Comms Server upgrade (and henceforth WorkSite Server, and eventually IDOL indexer…).

      Thanks again Sandy!

  • Hi Sandy. Great site!

    I just have a quick query in relation to database servers. Due to I believe was oversubcribed virtual servers we split off our WorkSite database some years ago onto it’s own separate SQL database server.
    In your experience, do many sites put their WorkSite databases on one consolidated SQL server or do they try and separate it out?
    Now that we upgraded our virtual server infrastructure some time ago I am thinking about moving our WorkSite database onto a new 2008 R2 SQL box.
    Thanks again,
    Michael

    • Thanks, Michael!
      Generally the WorkSite’s SQL database shares a SQL Server with databases belonging to other applications. WorkSite is not so SQL-intensive that it needs dedicated database hardware as a rule. Clustered SQL Servers are somewhat common where firms are looking for both resiliency and better performance.

      If you find yourself needing to run SQL 2005 as well as SQL 2008 due to application compatibility, I recommend looking into SQL instances. They’re designed to allow different SQL versions all to run on the same base server. Not in VMs: really coexisting on the same server. Seems to me that it’s a nice way to decouple your application upgrade cycles from each other.

      • Thanks Sandy.

        I will look into SQL instances if we have any applications that don’t support 2008 R2 databases.

        Just some clarification on your point here “Not in VMs: really coexisting on the same server. Seems to me that it’s a nice way to decouple your application upgrade cycles from each other.”

        Are you saying it may be worthwhile to keep the WorkSite database separate when dealing with VMs? My instinct is to reduce our number of SQL servers so that we have less licensing and management costs (we are only a mid-sized firm and run all our own infrastructure) but I don’t want to impact performance or go against accepted practices when it comes to WorkSite databases.

        Thanks!

    • Off the top of my head, I know of two firms that have used it this way for years – starting with version 6 currently on version 8.5.

      • By the way, seems that renaming ODBC after library was in use for some time is not an option, as all old links (created while library was in use with old name) became broken and it’s not clear how Indexer will react on such renaming… Is there are any others options for library rename (not on initial design stage)?

Leave a Reply

Your email address will not be published.