SQL Server Management

In my experience I have noticed that many different companies do not manage their database correctly, or even at all.  I have included a link to the Microsoft TechNet article describing strategies for managing your SQL database.  There are lots of helpful hints pertaining to log management, backup and restore procedures, rebuilding faulty system databases, importing and exporting data, and even copying databases from machine to machine.  This light reading will make you more aware of some possible issues and provide you with basic knowledge of recommended procedures to get the most out of your SQL Server.

http://technet.microsoft.com/en-us/library/ee210540%28v=sql.105%29.aspx

Andrew Skovran
Support Engineer
ImageSource, Inc.

Database Lookups Made Easy

Database lookups are easy with ILINX® Content Store.  Recently I configured a few and thought I would share some of the features.  I am assuming that you are somewhat familiar with database lookups in general, so this is not a step-by-step but just to point out some cool features.

Here is the application that we need a lookup for and we are going to base it off the SSN field.  We will need to click edit on the field and enable/configure the lookup

Fill in all the information to make the connection.  Continue reading

Installation Hand Off to the Client

As an integrator there are many things we can do as far as making the install a success, but only a very limited amount we can do to guarantee its continuing success. One of the most often seen issues is the handoff of an installation to the client, in particular the maintenance of the database.

Continue reading

Slowing Down?

For those of you with Enterprise Content Management systems, you know that a lot (if not all) of your data is stored in a database.  A lot of times, performance issues are not a result of your Content Management system itself, rather your database is not tuned properly.

Continue reading

It’s All About the Database

The key component to any content management/archive/workflow system is the database. Many times this key component is overlooked at the time a new imaging system is put in place, often the database is placed on an existing server which already has many critical duties or it is a new install placed on the same server as the imaging system software. These choices might be fine for a proof of concept, but as a system takes on more data and more users the database becomes the performance bottle neck.

As with any database, issues will rarely arise within its first year of usage, the data is slow to grow and performance of queries is quick and responsive since the load put on the system is minimal. During this time with minimal data the number of active users in the system at any one time is low as well. There are more inserts taking place than data retrievals. But the point of putting in one of these systems is not that the amount of data and the number of users will remain small for any length of time; most organizations bought their software and underwent the installation and configuration process with the goal of creating a vast repository that would make access to their content easy and quick for a large community within their organization.

It is when the system has finally been adopted fully and has enough content to be useful that the undersized database server will start to become a problem for the return of data to the users. I have seen systems where the input of new data is scheduled to go in during the off hours to compensate for the inability of the database server to perform inserts as well as retrievals during business hours. By this time the money for the original project is long since gone and often times the stake holders have forgotten about the decision to use a less than desirable database server configuration as a short term solution during the software’s “Pilot phase”. Continue reading