We recently moved from SQL7.0 with the included MX (DataDirect/Merant) JDBC
drivers, to SQL2000 with MS provided JDBC drivers and it was (aside from
microsofts non-standard jdbc uri) simple. In other words

> believe a third-party JDBC driver would be managed just like one of the
drivers included with CFMX,

is true.

Rob

http://treebeard.sourceforge.net
http://ruinworld.sourceforge.net
Scientia Est Potentia

-----Original Message-----
From: Phil Costa [mailto:[EMAIL PROTECTED]]
Sent: Monday, December 09, 2002 5:44 AM
To: CF-Talk
Subject: RE: Java in CF (CFMX) - MM Drivers


Better late than never ;-)

All the drivers are from DataDirect/Merant except for the mySQL driver.

I believe a third-party JDBC driver would be managed just like one of the
drivers included with CFMX, but I have to verify that.

Phil

-----Original Message-----
From: Joe Eugene [mailto:[EMAIL PROTECTED]]
Sent: Saturday, December 07, 2002 11:01 PM
To: CF-Talk
Subject: RE: Java in CF (CFMX) - MM Drivers


>Anybody from MM Product Team can explain this? on November 24, 2002
>5:24 PM

Product Teams reply 2 weeks later on the Thread!. Talked to Sean and figured
out this already. Anyways since you mentioned it, Are all CFMX Native
Drivers "DataDirect" Drivers(Oracle,DB2 UDB). If you configure a Type IV
Native Datasource in CMFX... Does CFMX manage connection pooling? Single
Connection.. Multiple Statements? How does this work?

Thanks
Joe


-----Original Message-----
From: Phil Costa [mailto:[EMAIL PROTECTED]]
Sent: Friday, December 06, 2002 4:49 PM
To: CF-Talk
Subject: RE: Java in CF (CFMX) - MM Drivers


It's throwing that error because you're trying to access the JDBC drivers in
an unlicensed fashion. The DataDirect drivers are licensed for use with
ColdFusion, which includes support for JSP as well as CFML, not the scenario
you're describing.

Phil Costa
Sr. Product Manager, ColdFusion
Macromedia



-----Original Message-----
From: Joe Eugene [mailto:[EMAIL PROTECTED]]
Sent: Sunday, November 24, 2002 5:24 PM
To: CF-Talk
Subject: RE: Java in CF (CFMX) - MM Drivers


I got this partially resolved... Sean helped out.. Thanks Sean. It was a
classpath problem. However after i load the
drivers(macromedia.jdbc.MacromediaDriver) which is in the "lib" directory of
your installation(eg. "G:\CFusionMX\lib\macromedia_drivers.jar") and give it
the connection url.. Connection con =
DriverManager.getConnection("jdbc:macromedia:sqlserver://SqlServerName:1433"
,"userid","Pwd");

I get an Exception..
"macromedia.jdbc.MacromediaDriver$InvalidLicenseException: An Enterprise
license is needed to use the Macromedia JDBC Drivers on the DB2, Oracle,
Sybase and Info rmix servers."

I am running CFMX Enterprise version(6,0,0,48097).  I have the same
connection working fine in JSP Pages under CFMX. Are CFMX Enterprise drivers
protected from usage in Java Applications(Console/Swing)? Anybody from MM
Product Team can explain this?

Joe


> -----Original Message-----
> From: Joe Eugene [mailto:[EMAIL PROTECTED]]
> Sent: Friday, November 22, 2002 4:11 PM
> To: CF-Talk
> Subject: RE: Java in CF (CFMX) - MM Drivers
>
>
> I can use the CFMX MM DB drivers in a JSP page..No problem. however..
> i need to use it in a Java Application..tried to load the Driver..
> Class.forName("macromedia.jdbc.MacromediaDriver")
> Keep getting ClassNotFound Error..
> I put the macromedia_driver.jar in the class path.. still not
> loading.. Do i need to import something? What am i missing?
>
> Joe
>
> PS:Old Thread.
> I am just catching up on this Thread..
> Isnt the idea to comply with J2EE Architecture? Model-View-Controller
> model etc.. Why would some want to write in-line Java..? Anyways...
>
>
>
> On Fri, 22 Nov 2002 09:09:16 -0500 Phil Costa <[EMAIL PROTECTED]>
> wrote:
>
> > The decision to disallow inline java code was
> > definitely not a cut and dry one. One reason
> > was definitely to enforce a cleaner separation
> > of syntax; the other, which I hadn't mentioned,
> > was to remove some additional complexity from
> > the parsing/compiling process. Because of the
> > differences between typing and syntax, parsing
> > a page that had both Java and CFML/CFScript
> > would have been a bear.
> >
> > Phil
> >
> > -----Original Message-----
> > From: Jon Hall [mailto:[EMAIL PROTECTED]]
> > Sent: Friday, November 22, 2002 2:37 AM
> > To: CF-Talk
> > Subject: Re: Java in CF (CFMX)
> >
> >
> > Thursday, November 21, 2002, 11:54:58 PM, you
> > wrote:
> >
> > MT> Jon Hall wrote:
> > >> The case for allowing inline Java is simple,
> > CF developers can use
> > >> Java without having to know everything about
> > Java. Methods and
> > >> classes are easy to get. Compiling,
> > classpath's, and understanding
> > >> the lengths Java goes to, to abstract
> > everything, etc. is not.
> >
> > MT> Knowing just a little about a language as
> > deep/complex as Java can
> > MT> be "dangerous" in a number of ways...
> >
> > MT> It's very easy to run into errors in java
> > if you don't understand
> > MT> how it all works (ex. trying to instantiate
> > an interface).  One of
> > MT> the overriding strengths of CF is that it
> > offers a great deal of
> > MT> power in an easy to use/learn style.  This
> > sort of thing, IMO, goes
> > MT> against that strength.
> >
> > MT> Mixing CFML and Java can very quickly lead
> > to code that is horribly
> > MT> organized and difficult to follow/maintain.
> >  Obviously, anal coders
> > MT> will keep things nice and neat, but others
> > will be mashing CFML,
> > MT> CFScript, Java, and SQL together
> > haphazardly.
> >
> > MT> Then there's the compatibility thing...
> > Java lists != CF lists.
> > MT> Java arrays != CF arrays.  Etc.  Again,
> > this can lead to confusion
> > MT> and cause all kinds of errors.
> >
> > I say let the coders (and the pm's who have a
> > clue ) who write the applications make the
> > decision on what works in their application.
> > I'm not trying to be facetious, but be brutally
> > honest, I couldn't care less that anyone else
> > thinks my hypothetical hybrid Java/CF code is
> > unorganized or difficult to maintain, as long
> > as those that it matters to, like my boss and
> > clients don't care either. So I don't see how
> > the fear of some overwhelming horde of
> > organized code existing somewhere out there,
> > just over the horizon, really is a valid
> > argument against allowing inline Java within CF
> > templates.
> >
> > >> CFQuery is the perfect example here. If CF
> > gives developers the power
> > >> to do whatever they want within cfquery
> > tags, then why not java
> > >> within cfjava tags? Seems's inconsistent to
> > me. Especially since
> > >> cfquery probably the biggest strength of the
> > CF language.
> >
> > MT> SQL and CFML serve 2 different purposes,
> > database manipulation and
> > MT> application logic.  Java and CFML serve the
> > same purpose,
> > MT> application logic.
> >
> > That's not entirely true. TSQL and probably
> > PLSQL work fine within cfquery tags. Terrible
> > as it may sound, if I want to loop over a
> > cfquery that manipulates a cursor I can.
> >
> > I'm not saying there are not valid reasons for
> > disallowing inline Java, I'm just saying that
> > limiting the flexibility of CF just because of
> > the possibility that nasty code may come into
> > existence is not a good enough reason in my
> > opinion, but it's the only one that's been put
> > forward by both you and Phil. I also don't want
> > to start yet another debate about what's good
> > and bad for CF, but as you said earlier, I am
> > curious as well. Though I suspect it's similar
> > reasoning behind not allowing cfscript to call
> > tags in the past (not that I ever got the
> > reasoning behind that either).
> >
> > --
> > jon
> > mailto:[EMAIL PROTECTED]
> >
> >
> >
>




~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4
Subscription: 
http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribe&forumid=4
FAQ: http://www.thenetprofits.co.uk/coldfusion/faq
This list and all House of Fusion resources hosted by CFHosting.com. The place for 
dependable ColdFusion Hosting.

Reply via email to