Re: CFMX ODBC/JDBC Drivers

2005-01-28 Thread Paul Hastings
>Real world users should be reading from the database significantly >more than they should be doing anything else. depends on your world. in our municipal info system world they beat the crap out of the db during tax season. pretty much constant reading/updating/deleting/reporting for an intens

Re: CFMX ODBC/JDBC Drivers

2005-01-26 Thread Alin Sinpalean
> Give me an example of exactly what I should do and I will do it. I don't know how this should look in CFML but I will give you the equivalent Java code; I think it won't be hard for you to figure out what I mean. Here goes: Statement stmt = conn.createStatement(); for (int i = 0; i < 100; i+

Re: CFMX ODBC/JDBC Drivers

2005-01-26 Thread Robert Everland III
Give me an example of exactly what I should do and I will do it. The reason I didn't do anything other than a select was that my view was that ColdFusion then has the result set so there would be no more use from the SQL server. I do everything in stored procedures, how are the results when usi

Re: CFMX ODBC/JDBC Drivers

2005-01-26 Thread Alin Sinpalean
> If you saw my code you saw that the only thing I was doing was a > select statement to the SQL server. The reason the second test was so > fast was because I left caching on, so that I would get a more real > world result. Ok, I see. > As I said earlier, I have no reason not to use JTDS, as

Re: CFMX ODBC/JDBC Drivers

2005-01-25 Thread Robert Everland III
I did my tests on a new coldfusion install, with 6.1 updater and all the hotfixes. Bob ~| Discover CFTicket - The leading ColdFusion Help Desk and Trouble Ticket application http://www.houseoffusion.com/banners/view.cfm?ban

Re: CFMX ODBC/JDBC Drivers

2005-01-25 Thread Robert Everland III
If you saw my code you saw that the only thing I was doing was a select statement to the SQL server. The reason the second test was so fast was because I left caching on, so that I would get a more real world result. As I said earlier, I have no reason not to use JTDS, as a matter of fact if t

RE: CFMX ODBC/JDBC Drivers

2005-01-25 Thread Katz, Dov B (IT)
ld be published somewhere? -Dov -Original Message- From: Alin Sinpalean [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 25, 2005 3:30 PM To: CF-Talk Subject: Re: CFMX ODBC/JDBC Drivers Robert, I am a jTDS developer and I can tell you (and you may choose to believe me or not) that jTD

Re: CFMX ODBC/JDBC Drivers

2005-01-25 Thread Alin Sinpalean
Robert, I am a jTDS developer and I can tell you (and you may choose to believe me or not) that jTDS is definitely faster than the MS driver. I'm not familiar with CF but from what I can tell you are doing no processing of the results returned by the query, so the test is a bit irrelevant. You

Re: CFMX ODBC/JDBC Drivers

2005-01-25 Thread Adrocknaphobia
Quick question, do the non-datadirect drivers support the return of Ref Cursors as a coldFusion query? -Adam On Wed, 26 Jan 2005 01:13:56 +0700, Paul Hastings <[EMAIL PROTECTED]> wrote: > Robert Everland III wrote: > > I would like to see the test you ran to see why are test vary so > > signifi

Re: CFMX ODBC/JDBC Drivers

2005-01-25 Thread Paul Hastings
Robert Everland III wrote: > I would like to see the test you ran to see why are test vary so > significantly. Were you using the latest Microsoft JDBC drivers? I am using > the latest of every driver in this test. yes the very latest drivers were used (though again, mm has an even newer driver

Re: CFMX ODBC/JDBC Drivers

2005-01-25 Thread Robert Everland III
Ok here is some quick testing I ran on the different datasources to compare speeds, I wanted to do it as quick as possible, before the thread dies off. I didn't really care which one won, I just want the fastest possible drivers. No settings have been changed. Classes were deleted after each tes

Re: CFMX ODBC/JDBC Drivers

2005-01-25 Thread Nick de Voil
> > comparative testing of these aspects as well as performance, or do you know > > of any such testing that's been done? > > nope. are you volunteering? Well... we'll start by trying it out in a couple of apps & if we find out anything interesting will post it. Thanks Nick ~

Re: CFMX ODBC/JDBC Drivers

2005-01-25 Thread Paul Hastings
Nick de Voil wrote: > As well as performance, other aspects to a DB driver are stability & > functionality (like support for SQL syntax & the JDBC spec). Did you do any functionality is pretty much what you'd get from the other two drivers (except the datadirect driver that ships w/6.1 has a bug

Re: CFMX ODBC/JDBC Drivers

2005-01-24 Thread Nick de Voil
Paul > pretty much everybody knows better than ms when it comes to JDBC & sql > server. ms's JDBC driver originally came from datadirect & hasn't really > progressed that far. and my own testing is exactly the opposite of your > findings, ms's JDBC driver was the 3rd slowest i tested: > > #1 jTDS

Re: CFMX ODBC/JDBC Drivers

2005-01-24 Thread Paul Hastings
Robert Everland III wrote: > If you are using SQL Server 2000 you can always use SQL Server JDBC drivers. > Who better than MS to know how to handle their own server. I did some testing > by looping through different types of queries such as inserts, updates and > selects and with just 1000 quer

Re: CFMX ODBC/JDBC Drivers

2005-01-24 Thread Robert Everland III
If you are using SQL Server 2000 you can always use SQL Server JDBC drivers. Who better than MS to know how to handle their own server. I did some testing by looping through different types of queries such as inserts, updates and selects and with just 1000 queries Microsoft JDBC drivers were a c

RE: CFMX ODBC/JDBC Drivers

2005-01-24 Thread Steven Erat
. Steve > -Original Message- > From: Scott Wolf [mailto:[EMAIL PROTECTED] > Sent: Monday, January 24, 2005 4:16 PM > To: CF-Talk > Subject: CFMX ODBC/JDBC Drivers > > I was looking through the archives for solutions to a couple > of database problems that we

CFMX ODBC/JDBC Drivers

2005-01-24 Thread Scott Wolf
I was looking through the archives for solutions to a couple of database problems that we're having on one of our development servers. One solution that I want to try is rolling back the ODBC/JDBC drivers that come with MX 6.1 to the ones from MX 6.0. I've seen this suggested in several places