This was a dumb question in the making until I explored the dbinfo function a bit further and worked out what I was doing wrong and that led me back here to at least post my observation in case someone else falls into the same hole…
Basically, I wonder why I need to provide the ‘dbname’ parameter when using type=‘columns’ when the DB is already stored as part of the ‘datasource’ which (as far as I know) locks you into that specific DB anyway? Of course having said that the dbinfo function breaks that by giving you access to all the DB instances that the account used to create the datasource has access to (I assume - I haven’t explored that far yet).
So now I wonder if there is scope for dbinfo to default the dbname to whatever is in the datasource definition if it has not been specified?
Actually, this really is a bit of a problem, For example, on our QA DB server we have four or five different DB instances running, one for each QA environment that we have up at the time. In terms of DB ‘info’ it doesn’t (much) matter which one I use, except that different code branches might have slightly different schema. But the point is that I don’t know the name of the actual DB instance being used - that is abstracted into the datasource configuration…
dbnameshould be optional (according to the Lucee docs) and should only need to be specified if it differs from the one defined for the datasource (according to ACF docs). If that’s not the way you find this is working, then I’d definitely file a bug for it on Jira.
datasources are not limited to one database… if database is defined it should become optional in the tag/script imho…
We don’t put database name in the field and use a datasource across several databases in one app, and use datasources more as permissions (read only or read/write ds for each app)