I had a question from a reader who was having trouble with his client variables database. You don't have to be using ColdFusion for long before you learn (or are told) that if you are going to use Client variables it is important to use a database and not the registry. This goes back to the old CF 5 days when client vars could cause the registry to grow to astronomic proportions before anyone would notice.
The solution to Client variable performance has always been to move them to a data source on an RDBMS (MySQL, MSSQL, Oracle etc). The process is all done using the ColdFusion Administrator. It is a bit involved but not difficult.
Meanwhile, having explained the rudimentary steps for adding a client variable DSN my reader is impatience to hear his problem explained - so here goes. He created a DSN named "coldfusion" and used the steps above to insure that it was specified as the client variable DSN. He noticed immediately that the "global" variables were created, but no actual "client" variables were created. In other words, when he did something like "cfset client.user = 'bob'" it had no effect. Subsequent requests indicated that client.user did not even exist. Clearly the records were not being written to the DB.
After some trial and error I suggested that perhaps the datasource name of "coldfusion" was the problem. Why you ask? As a rule I never use what could be a reserve word as a variable or datasource name. I surmised that "coldfusion" seemed to fit that standard so I suggested he create a new alias and try again. As soon as he did the tables began to update. The moral of the story - don't use reserve words for things like variable names or DSN's. Meanwhile, if by some confluence of events and aligning of the stars you have chosen to name your datasource for client variables "coldfusion" and you are scratching your head to figure out why it isn't working - try renaming the DSN.