Scott Dexter wrote: > > > > - With ASP you don't get a lot of built in functionality. For instance > ... > > so the functionality of CF is beyond ASP in that sense. > > nnnnnnnope. Look at it the other way around. You can write your own dll to > do whatever you want, and call it from ASP. I know at this point CF must be > able to instantiate COM objects, but ASP functionality is *not* reduced > because ASP doesn't have things built in. Recall what Adrian said; ASP is I think adam was trying to say that CF has many of those functions you have to write for ASP *already* built in. Things like SMTP, POP, LDAP, and FTP handling to name a few. Sure, you can write a custom DLL in asp to do the same thing, but why re-invent the wheel? Just to clarify, you *can* write your own custom tag or COM, Java, CORBA, or C++ object with CF and integrate that into your application just as seemlessly as ASP could. > closer to the underlying OS, and while that may mean things aren't built in, > it also means a faster path for execution and the ability to get at whatever > you want.... The flip side to that of course, is you inherit the flaws of the OS you're so closely tied into. Without getting into *that* whole issue though.. > > - (correct me if I'm wrong on this) We had to use ODBC to connect to > > Oracle and SQLServer from ASP. ODBC isn't a super efficient way of > > connecting so that could be a disadvantage performance-wise. > > You can specify the OLE-DB provider to connect to the DB, and it is much > faster than ODBC. > example (all on one line): > "Provider=SQLOLEDB.1;User ID=IISUser;Initial > Catalog=Foo_db;Password=blahablah;Server=LocalServer" Native connections like OCI(oracle native call internface) will smash OLE or ODBC, which I think is what adam was trying to elude to. .djc.