I posted an article not to long ago that discussed a method of dynamically determining the Metastorm database name by using a server side script to look to the Registry. Although it makes sense not to hard code your database DSN’s into server side script (because if you change the name of your default Metastorm database, you’re screwed), it may not be the best way to tackle the problem. Not only that, I started to think about the use of record sets in server side code (handy for looping in Metastorm 7) and how I could build a connection string dynamically based on a DSN.
If we think about the OOP design principle of ‘coupling’… specifically that during the design of applications and the defining of interacting objects, we should ensure that each object knows as little about the internal workings of the other object as possible. When an object is dependent on a lot of the internal workings of an object it interacts with it is known as a tightly coupled relationship. This means that if the implementation code of one of the objects is to change, it could potentially ‘break’ the calling object.
To avoid this, it is generally good practice to design objects that are ‘loosely coupled’, meaning that your objects know as little as possible about each other. They would talk to a simple public method and that is all they would need to know about the object being invoked (using familiar OOP concept, encapsulation. The hiding of internal logic).
Ok, so it sounds like I’ve gone off track a bit. Back to the point at hand and my previous article about getting the Metastorm database name from the registry. When talking to the registry to try and determine what the name of the working Metastorm database is, we are having to understand the structure of the registry including the hives and keys. Therefore, this isn’t such a bright idea (hey, I’ll admit when I’m wrong!). So after some reflection, I’ve decided to use the DSN instead as this will provide us with the information we need, but also abstracts away the structure of the registry from us. We now don’t need to worry about keys and hives and all that Jazz.
So here’s an updated script that you can add to your utility box that will return a connection string to a calling server side method that might be performing some looping on an ADO.NET dataset or something (note, the single string parameter should be the name of the DSN, also you should ensure that the database connection string being built is the right one for your server. The below works for SQL Server with integrated security):
Apologies for the poor image quality – I’ve taken this snapshot from a procedure on a remote server that I’m RDPing to.