Are you sure you're looking at the cf admin of the instance where the code is running (to create the dsn via that admin api call, and to view it with that other call)?
For instance, you could either have multiple instances of cf (if you or someone else created them), or even on your own machine, you could have cf installed both on its own (admin at port 8500, by default) AND as implemented within cfbuilder (port 8600, by default).
Besides checking what port you're using, do also a cfump of the server scope, in the template showing the dsns via code, which will confirm where that code is running. Compare that to what's in the cf admin settings summary page.
Let us know how it goes.
Thanks for that. Everything was default with only one instance running. I did a restart of the Coldfusion Application server and the new ones appeared then. I should've thought to have done that previously. I suppose what confused me was when you add them via the interface in CF Admin they appear immediately and I was expecting the same to happen here. The next question would be is there a way I could get them to show without having to restart the server.
That's interesting to hear. I am not aware that the admin API calls like that would NOT take effect (appearing in the CF Admin) until a restart, but I suppose it's possible. It's just odd that clearly CF the ENGINE knows about the change, immediately, because you could see it with other code on that server. I would not expect you should HAVE to restart the CF Admin to see it in there, no.
FWIW, you haven't said what version of CF you are on, or what update. If you are not yet on the latest CF updates (10 for CF2018, 16 for CF2016) or on a still older CF version, perhaps this was a problem in the past that has since been fixed. If you ARE on the latest CF update, that would indeed be odd.
In that case, it could be interesting to hear if others may get to try this out to see if other settings (set via the Admin API) may not "appear" in the CF admin immediately, and until a restart. I'm afraid I'm not in a position to test this as I write, and I may not get to it, but I put this out in case you or others may be interested to dig further.
If it is happening in the latest CF versions, it would be something you should report as a bug at tracker.adobe.com. Adobe really does pay attention to those. They don't fix EVERY bug, but they do fix a few hundreds per year.
paulm1677332: I suppose what confused me was when you add them via the interface in CF Admin they appear immediately and I was expecting the same to happen here. The next question would be is there a way I could get them to show without having to restart the server.
Yes, there is a way to show the new datasource in CF Admin without having to restart the server. First, let's get a misunderstanding out of the way.
When you add a new datasource in CF Admin, it does not appear immediately. The last step in the process involves clicking on the Submit button. The action page of the form is the CF Admin page. So what you see is a new request.
Behind the scenes, the click triggered a form submission to a URL, such as
In other words, a POST request to the URL, including the properties of the new datasource as form data in the request body.
You can verify this yourself as follows. Open the CF Admin datasource page and press on F12 (to open Developer Tools). Add a test datasource. You should then see the details of the POST request.
This tells us that, after you add a datasource programmatically, you have to reopen the Administrator datasource page.
I have logged out of administrator and back in again and it still doesn't show. So I take your point that it works there without a server restart but what else is run that allows it to show in datasource list immediately. Only way I was able to see it was with a server restart.
I am running CF2018 with Update 10
Here's my understanding of the problem. When CF starts, it reads a bunch of XML files that contain various bits of configuration info into memory. During its normal operation, it's not rereading the files from disk, it's just using what's in memory. Then, when you shut CF down in an orderly manner, it writes those changes back to the files.
So, when you call a function that changes the configuration, it changes that configuration in memory, not on disk. It'll stay in memory until CF is shut down in an orderly manner, then will be written to disk. When you change CF via the CF Administrator, I suspect CF is writing the information to disk, then rereading it from disk so it can be shown to you, or at least the CF Administrator knows at that point to show you what's in memory instead of what's on disk.
I'd just post this as a bug and see what Adobe does about it, if anything. As you noted, it doesn't really affect the overall behavior of CF, so they might not do much about it right now.
Dave Watts, Eidolon LLC
I'm half ways through logging a bug on another tab. We'll see what they come back wit.