DSN-Less CFQuery
I was thinking about a problem yesterday and one of the crazy thoughts that ran through my head was "man would it be cool to be able to run a query against a database without having to configure a DSN". This solution is not shady in any way as it still requires you to have the proper credentials but it would be helpful at times when you need the ability to have a "throwaway" query. I suppose there are other potential uses for it - but I really just wanted to see if I could do it. Turns out it was very easy. I wrapped it in a quick custom tag so that all you need to do is something like this:
select *
from theTable
where something = 'foo'
and otherstuff = 'poo'
</cf_query>
<cfdump var="#test#">
Now you may be asking yourself well what the heck is a jdbcURL and how can I tell what I'd use here. Simple (but it takes a bit of undocumentedness):
<cfset dSourceService = factory.dataSourceService />
<cfdump var="#dSourceService.getDrivers()#" />
This will give you a list of all JDBC drivers on your machine along with a sample jdbcURL. Nice!
I've included a zip here if you'd like to play with it. I could go further with it and add support for query parameters but I'm not sure if it's worth it. Thoughts?



Like you, I'm not sure what the use case would be for this, but cool anyway.
Here's my cf_query call:
cf_query jdbcURL="jdbc:mysql://127.0.0.1:3306/myDBName" username="root" password="myPass" qName="test"
Matt, to get MySQL working I had to add:
<cfset class = createObject("java", "java.lang.Class") />
<cfset class.forName("com.mysql.jdbc.Driver")/>
Before the call to the cf_query tag.
<cfset createObject("java", "java.lang.Class").forName("com.mysql.jdbc.Driver")/>
Interesting that it is just setting something. Must be something that is needed by one of the other java classes.
Matt,
Here is a brief explanation to class.forName magic
http://cephas.net/blog/2005/07/31/java-classfornam...
Thanks
http://cfsilence.com/blog/client/index.cfm/2007/11...
Right now, everyone looks the same to SQL Server - webuser.
I'd like to keep the login security at the database level instead of the application level.
Not different schemas - just different SQL Server logins.