In some environments and scenarios, I used to use initialization (*.ini) files for storing simple configuration settings. Now I typically store this kind of information in a ColdSpring configuration file, or at least in an XML file of some sort. But at times I have to live (and work) with the apps I wrote that use *.ini configuration files.

The nice thing about *.ini files. Not that they're all bad. It's ridiculously easy to extract settings from these files with ColdFusion. For instance:

To retrieve the mysetting configuration setting, I just make one call:

It can't get much easier than that to retrieve a value from a configuration file!

The bad thing about *.ini files. The only problem is that these files are restricted to name=value pairs of simple values. You may go into a project with no need for configuration settings that are any more complicated than simple numbers or strings, but what about 3 years from now when the business logic now could use some structs or arrays in the configuration?

Of course, you could change your whole configuration methodology when--and if--that time comes, but ugh. Using XML (especially in conjunction with IoC such as ColdSpring) is so much more scalable. The future you will thank you.

But it's too late. You and I already have complex app XYZ that is using *.ini config files, and you need to add feature X without rebuilding the configuration logic of the app. What to do?

Embed a string representation of your struct or array in the config file! After all, ColdFusion 8 allows implicit struct and array creation, right? Well, half-right. Doing something like x=Evaluate(myStructString) just isn't allowed by ColdFusion.

However, we can effectively do the same thing with JSON representations of structs and arrays. So, try this:

Now, retrieving mysetting with GetProfileString() will still get you a string, but using JSON functions built into ColdFusion 8 will get you a struct:

Your myStruct variable will be a struct with two keys ("one" and "two") just as you would expect from the JSON.

You could achieve similar results using XmlParse(), but in a case like this, the less verbose, the better. And JSON is less verbose than XML.

I am "stuck" with a few web applications that provide web front-ends to Access databases. I am not the owner of these databases, and for various reasons, the database owner will not upgrade it to SQL Server. Alas, this sometimes causes headaches like the following.

The Access databases are on a network fileserver. Occasionally, this server goes down or resets, and ColdFusion's datasource connection to the database gets stuck in a disrupted state. I've come to learn two things you can try to get ColdFusion's connection to the Access datasource working again without resetting the entire ColdFusion Application Server service, which is obviously disruptive to your entire site and all of its applications.

1. Reset the ODBC services. The ColdFusion ODBC services (such as "ColdFusion 8 ODBC Agent" and "ColdFusion 8 ODBC Server") actually handle the ODBC connections to DataDirect driver databases such as Microsoft Access databases. This is handy. Just reset these services and often connectivity is restored.
2. Use the "Disable Connections" option in the datasource configuration. If you are using JDBC drivers (for instance, perhaps to connect to Microsoft Access 2007 databases), resetting the ColdFusion 8 ODBC Server service won't help. Darn. However, if you go into the datasource's configuration in ColdFusion Administrator, you can check the "Disable Connections" checkbox and submit the change. This will force ColdFusion to disconnect from the database. Immediately go back in and uncheck the checkbox and submit again. Your datasource will now have connectivity reestablished without a ColdFusion restart!

Happy days! The second option won't be helpful to you if you have many, many datasources. However, this is better than a ColdFusion reset that would disrupt all of your apps.