Sure, JDBC is an option, and I had pointed out the HXTT driver in my earlier note. But I also pointed out there that people have solved this problem simply by also implementing a 32-bit datasource. I offered several links explaining that. Did you try it? It's worked for many. For those who missed it, it's here: http://forums.adobe.com/message/3101486#3046213 /charlie ... View more

Really great to hear, and thanks for the kind regards. Much appreciated. /charlie ... View more

Thanks so much for that. I didn't want to think you were slamming me, Adam, but it is a point of contention for some (anytime a message is more than a couple of sentences). Some problems simply call for longer explanations. I'm going to address my own desire to offer that in the form of a new podcast/call-in webradio show for CF troubleshooting that I plan to start. It will be at www.cf911.com, though for now it just redirects to a temporary landing page on my carehart.org site. /charlie ... View more

Well, that really ought to be a new forum thread (CF hosting alternatives). But I will point out that I have a page of them (and pointers to other such pages of them) as a category in my CF411 site: ColdFusion Hosting Alternatives http://www.cf411.com/#cfhost I can also personally recommend both EdgeWeb Hosting (https://www.edgewebhosting.net/) and FusionLink (http://www.fusionlink.com/) as two hosts who definitely know their CF Stuff and with whom I (or people I work with) have sites. /charlie ... View more

Beyond that, is it also a MultiServer (multiple instances) deployment? If so, is this the Admin of one of the instances that you're trying to open? Or the cfusion instance? As for the odd filename/path references, those reflect the original location of the files on the machine of the Adobe developer who precompiled the code (many CFML files in the CF Admin are precompiled or encoded so that you can't see the source. Errors that happen with them do show that original source location, which can be confusing.) To your issue, whether you're using Server or Multiserver deployment, can you confirm what directory was updated by the security update? And do you know (for sure) what directory had been used as the CFIDE directory for the CF instance you're trying to run? I realize you can't get into the CF Admin to confirm, but you can look in the \lib\neo-runtime.xml for an entry with the name , which has a child tag pointing to the location where that server expected to find its CFIDE directory. Things can get confused based on choices of whether one does or doesn't use CF's built-in web server, how one configures an external web server (like IIS), any manual tweaks one may do after installation. All this could confuse the security update process (or the person who ran it). Hope that helps get you started. Let us know what you find and perhaps I or others can help get you sorted. /charlie PS Can you clarify if you're trying this in a dev or test environment? Or is this production? And if so, had it worked in a previous dev/test attempt? ... View more

Adam, I was just answering his question. It wasn't a simple question, and simple answers didn't seem to be doing it for him, as had been demonstrated in many more words before I wrote my one reply. And to be honest, you've said as much in two subsequent replies as I did in my single 6-paragraph answer. And one of your notes repeated a point I'd already made. I'm only ever just trying to help. ... View more

Well, the "textbook" answer is that you can look at either the CF Admin "Setting Summary" page or the blue "system information" icon in the top right of the Admin. If you have applied any hotfixes or cumulative hotfixes, those will show up in a line on the page labeled "update level" in the first section of data reported at the top of the page. If there is no "update level" line, then you have not applied them. But you ask how to determine "which patches have been installed", and that really requires a much more involved answer. This will be long (and after I get any feedback, I'll turn it into a blog entry), but until then, here's a shot at an answer for you. 1) Beware that the info in the admin pages above shows only one hotfix, even if you have applied more. This is quite unfortunate. So to confirm "which patches have been installed", you technically need to look in the lib/updates directory (which is where the patches get put by the "update file" feature on the "system information" page). 2) So where are those updates stored/found by CF? Well, the easiest way for you to tell is if you have any other updates listed there. In that case, the info shown will indicate the directory where they have been put. If there are none, then it would seem to indicate that there are none yet applied, but you should double-check the directory to be sure. So where is it usually? Well, on a standard/server/standalone deployment, it's the /lib/updates directory, such as C:/ColdFusion9/lib/updates/. On the multiserver edition (multiple instances), it's instead buried deep within each separate instance. For the cfusion instance that would be C:\JRun4\servers\cfusion\cfusion-ear\cfusion-war\WEB-INF\cfusion\lib\updates. For other instances, it's just a little different: C:\JRun4\servers\instance1\cfusion.ear\cfusion.war\WEB-INF\cfusion\lib\updates (the cfusion instance uses dashes for some of the dirnames, where other instances use dots. Confusing, yes. (And if anyone is wondering, this does also clarify that yes you must put hotfixes in each instance. You can't just put them in the cfusion instance and expect that to update other existing instances. It doesn't work that way.) So to your question, I'm saying that you need to look at that directory to see what's there, to know what hotfixes or CHFs have been applied. CF reads all of them there. You don't want to rely solely on what's listed in the "update level" info on the Admin pages above. 3) I'll share one other tip: make sure that any files you see in that directory are for the version of CF you have. The Admin "update file" feature does not validation, and I've seen many people have the wrong hotfixes for their server, such as chf8000001.jar in an 8.0.1 environment (or as bad, a CF9 environment). That 800 in the jar file name means that's for 8.0. An 8.0.1 hotfix jar file would look like chf8010001.jar. The problem is that Java loads any classes in any jars in the classpath (and this updates directory gets put into the classpath), so you could inadvertently be causing problems if CF is loading the wrong classes out of one of these "wrong" jars for your environment. A cause of subtle bugs, I think. 4) And again, in that you seem to be asking to know how to confirm "all" patches/hotfixes that have been applied, technically you can't even rest on looking in the lib/updates directory. Many Cumulative hotfixes (and some hotfixes) do in fact indicate multiple manual steps asking you to update files that may exist in any number of other directories. So there's simply no way to know "have all I need been applied", if that's what you mean, or "have all I need for a given CHF been applied". For that, you'd simply need to look at the hotfix docs to confirm what needs to have been done. 5) That points to one more gotcha that many suffer: be careful not to stop at applying "the latest" cumulative hotfix. Let's say you are on 8.0.1, with no hotfixes (or only the first 1 or 2), and you see that there is a CFH 4 out there. While it's technically true that by applying the CHF jar file in CHF4, you don't then need to do the one for 3 (or 2 or 1, etc.), what's NOT as obvious is that this only takes care of the CHF JAR file. Again, if one of those earlier CHFs had multiple steps in addition to just the CHF jar, you need to do those. This was in fact the case with 8.0.1 CHF3, which lists a separate manual step required for fixing a CFIMAGE bug (and beware that it lists that at the top of the hotfix page, not at the bottom under the "steps to follow", at http://kb2.adobe.com/cps/511/cpsid_51180.html). If you jump to CHF4 from before CHF3, if you miss that manual step in CHF3, you will still suffer the problem. Bottom line: you should always scan all preceding CHFs for a release before skipping them to "go to the latest". Sadly, even the hotfixes don't warn of this, though I did add comments to this regard to the 8.0.1 CHF 4 (http://kb2.adobe.com/cps/529/cpsid_52915.html). 6) Along the same lines, when you move up to a newer CHF from an older one, you should delete or remove the previous CHF jars for that version, if there are any in the lib/updates directory. And be careful trying just to rename them and keep them there "for backup". Again, Java loads classes in any .jar files, you if you rename chf801001.jar, for instance, to chf801001_old.jar, you've done nothing. Java could still load those classes. You could rename it to .jar.bak. It may be best just to delete them, or move them to some other directory entirely outside of CF so that there's no chance it's picked up on its "classpath" (which it builds at startup due to various configuration entries in the Admin or config files.) 7) Yes, I do realize that this all points to a rather lamentable state of affairs with respect to hotfix management. It could certainly be a lot better managed, require less manual effort, require less worry about what has or has not been (or still needs to be) applied. Perhaps Adobe will address that in future releases. 8) In the meantime, there is one free tool out there that tries to help with all this. It's called Merlin Manager, and available at merlinmanager.com. It's definitely worth checking out as it has a lot of nice features to help with all this, including letting you know what updates you need for the version you have, doing that across multiple instances, and much more. That said, I don't know if it solves all the gotchas I've warned of above: I don't know if it deals with checking for whether you have any jars in lib/updates that are "wrong" for your version, nor do I know if it checks for if you still have unneeded older CHF jars there, nor do I know if it checks for whether any "multi-step CHFs" have had all their steps done. I'll email the maker, John Mason, to ask him to confirm and point him here to offer an answer. 9) Finally, whether John handles it or not, I do think it would be helpful if someone (Adobe, someone else) came up with a list of what CHFs for each release did have manual steps that need to be done, so that we could more easily know (when we apply a later one) which earlier ones we need to pay attention to. I'll be interested to hear any feedback to all the above, and then I will blog about it. It's a topic that many could benefit knowing more about. /charlie Providing CF troubleshooting services at carehart.org/consulting charlie@carehart.org ... View more

Nope, no knowledge of any Oracle details on this. Sorry. /charlie ... View more

OK, I think this discussion is getting confused among matters related to the dev edition, the new CF9 license key, and hosting. Let me see if I can help you, "teedoffnewbie". It might even be useful info for some other readers of this thread. About the new CF9 licensing terms, those are for folks who buy a license of CF9 (which would usually to be deployed on a production server). For them, they can take the license key from that production server and use the same key on a local or test/dev server. It's this permission to use the one key on multiple machines (one dev/test for each prod key) that is new in CF9. So here's a key question for you: you refer to a hosted server. Are you saying you bought a CF license that's deployed there? Or do you just mean the host bought a CF license and you're just one of many customers on that shared host? In that latter case, then as far as I understand things, you would NOT be able to use their key on a local/dev server. I mean, in such a shared hosting setup, one can't even see the license key, typically, as the host doesn't let such hosting customers have access to the CF admin. But it does raise an interesting question, of whether this was at all something Adobe had considered. I am inclined to think that perhaps they did not. Hosting deployments often get kind of short shrift (some would say). I think they would also assert, though, that what you are trying to do is to use CF on your "local" machine as effectively a production deployment. Would you say otherwise? It's not really clear what you're trying to do. I know you've tried to make it clear, but it may be useful to clarify. If you mean you want to have some "local" db/file to be updated by CFML code running on a "local" machine, but to be hit by multiple users, then that would seem a separate "production" use of CF. It's not really significant that it's local vs remote, or a "PC" versus a "server". Finally, you downloaded the "development" edition of CF, and that's what people have been responding to from your initial note. The free development edition is specifically limited to no more than a few IP addresses for people to hit that CF instance, and that's why some noted that you could restart CF to refresh that list. That's how to technically get around that limit, which might be legit, for instance, if a development company might make the server be open to web access and they used it to first show customer X the work they were doing for them, and then they later needed to show customer Y their code on the same CF server. In that case, a restart of CF would permit that. But as everyone has been getting at, this development edition not intended for production use. Does that help? /charlie Providing CF troubleshooting services at carehart.org/consulting charlie@carehart.org ... View more

Oh, ok, thanks for the clarifications Fabio. Sorry you felt my last reply wasn't helpful. I just don't think it was not clear (to me) that you were asking for help in transitioning to doing development in CFBuilder. (Since there have been lots of recent requests in these forums from people asking general CF questions, I have been pointing such people to the other forums. Now that you've made yourself more clear, then yes this is a suitable place for the discussion.) I'm sure others will chime in, but the whole subject of remote development is one on which you'll get widely divergent opinions. - Some will assert one should never, ever edit files on a remote server, and that the only "right way" is to use a source code control system (as you're doing). - Others happily edit files remotely (yes, it is an option in CFB), though they do it at their peril if they make a mistake and don't have something to recover to. - Still others keep a local copy of code, and edit and test that, then push it up (without any source code control, though given the built-in "local history" feature of CFBuilder, they do have a poor-man's version for recovering old versions if needed.) All that said, I don’t' know that you'll get agreement on any one "best practice". Arguments can (and would) be made for either approach (and yes, though some don't realize it, you can do any of the approaches above in CFB). You say you're coming from JEE development. Did you use Eclipse for that? How did you work there? There's not really anything about CF development that would differ than what you may have done with Tomcat, JBoss, Glassfish, Jetty, Websphere, etc. And I now realize you said in your first note that you "can use SVN". I read that as if you were using it already. If you're saying you are not, then it sounds like you're open to alternatives. I think most would agree that the most mature software development practice is indeed to use some version control (whether SVN, GIT, CVS, or the like; and each of those has its vocal adherents who will swear that doing anything else is pitiful). And since CFBuilder is based on Eclipse, there are many plug-ins for Eclipse for working with any of these. Whether an individual developer should take up any one, and which plugin is best, is really a tough situation in which to make absolute recommendations--kind of like recommending "which framework is best". There are just so many variables. And really, your very point about pushing code to a remote server for deployment opens yet another can of worms that's not often covered in some books/articles/discussions about using source code control. Beware of that (as some resources are more focused on desktop app development, which is quite different). I realize this again hasn't "answered your question". I'm trying to say that you may have a hard time getting any one answer (and typically people answer only very briefly). This is not a new dilemma (how best to do version control with CF). Indeed, one of the very first CF presentations I gave was in 1998 was on the topic (with regard to a tool that was bundled with CF at the time--anyone remember Starbase Versions?) People have been trying, rejecting, recommending different solutions ever since. It's just a notoriously difficult question, with so many SCC alternatives, different deployment scenarios, different editors. I'll just say again that nothing about CFBuilder and CF is really that unique: you may get as much or more information asking about this on a more java-centric forum regarding Eclipse. The same concepts apply. That just may get you before a larger audience. Not only is CFBuilder new, but there is this tendency in CF for some people to got the easy route (direct remote editing). You're right to seek "the better way", but you may want to widen your field of research to find more people who've been down that road and can speak competently about the pros and cons of various routes. So do I have a recommendation myself? Not really. I don't do full-time development (I focus on CF server troubleshooting, and on helping people use various aspects of CFB, especially its connection to CF), so I have not had to engage in remote deployment from version control since moving to CFB, and I didn't use Eclipse before that. I'm sure that's "showing my stripes" a bit in the mind of some, but the point is that for the small amount of remote deployment I do, I get along fine with either local testing and FTP push, or just occasional direct editing. But I've offered the above as an observer of the playing field, who has seen many of the conversations come and go. Hope that's at least a little more helpful. /charlie ... View more

Fabio, you refer to using Dreamweaver. This is the ColdFusion Builder forum, which is about the new IDE for CF. While some may respond here with thoughts on remote development, it really isn't the best place for you to be asking your question. If you don't get satisfactory answers (or even if you do, but you want to open the discussion to a still wider audience), you should consider asking it on the main CF or DW forums: http://forums.adobe.com/community/coldfusion/coldfusion_general http://forums.adobe.com/community/dreamweaver/dreamweaver_general And really, since you're asking primarily about best practices with SVN, you would be well-served by asking on some SVN-specific forum, though admittedly some comments would apply readily regardless of the source code control solution one may use. While not a direct response to your question, I hope some of that's helpful. /charlie ... View more

Hi Bill, yes, I can offer such help. In fact, I've long thought about offering a low-cost, fixed-fee option to solve any single problem. Your request here, and another earlier today, have prompted me to go ahead and set that up. It's now enabled as a new engagement type at my http://www.carehart.org/consulting/ page (where I also discuss how I offer this as remote consulting, via Adobe Connect, which I usually perform in providing CF server troubleshooting.) I help people solve problems with CFBuilder all the time (here and in other mailing lists), and I speak and write about using it extensively. Still, some problems are just difficult to solve in email (plus there's no guarantee of one getting a reply from anyone, including myself, here). So I'd long considered offering a service to fill that gap. The two notes today prompted me to proceed with it. You'll see it on the page as a "CFBuilder fixed-fee/single problem" option, for a flat $US75. That's for help in getting any one thing to work in CFBuilder, such as getting debugging to work, getting RDS to work, getting code insight to work, getting the ctrl+hover hyperlinking to work, solving slow performance problems, and so on. Now, if someone gets their hackles up at the thought that they should have to pay for getting a problem solved with CFB, well, of course, you don't have to pay. That's why these forums are here. But as Bill says below, sometimes people are just willing to pay to solve a problem, and again some problems are just hard to do without being able to see what's going on and more easily explain how things need to be configured. If paid support is not a solution for some readers, that's understandable. (I addressed this a little more in a lighthearted mention of the new option in my reply to the other forum thread here earlier today: http://forums.adobe.com/message/3056104#3056104). My hope would be that, with my experience solving problems, we should be able to solve most of them quickly, which is good for both of us. I'm willing to take that risk and keep it a fixed fee (compared to my normal hourly rate of $US175 for CF server troubleshooting). Of course, the fixed fee means there's no prorating of it if solved quickly. Think of it like a plumber, who has a fixed price for a service call, even if just to plug a single leak. You're not paying for the time to plug the leak (nor even to drive over), but for the value of stopping the leak, the plumber's knowledge of how and where to solve the problem, and his setting up a business to be there when you need him. Conversely, though, there are sure to be some problems where I just can't solve them, even after a couple of hours (they may even be bugs in CFBuilder). In that case, to protect both of us, I offer the option to refund your money after those 2 hours (unless you feel there was still value in other aspects or information shared during the call). Hope that's helpful, to Bill and to others. Feel free to mention it to others who may appreciate this when struggle at length with some CFBuilder problem. /charlie ... View more

MPRyan, I have an observation and some suggestions. First, I'm afraid there are just too many things that could be amiss, whether in your setup of the Debug configuration, the project, the CFB-to-server definition, the CF server configuration, your firewall, and so on. It would be difficult to list all the things you may want to check, that perhaps either you have not configured, or not configured properly. Second, of course you'll want to be sure to have read the CFBuilder docs (whether within the IDE or on the Adobe site's docs pages). You may find something discussed regarding any of the things above that you may have gotten wrong. Third, I've done a recorded presentation specifically on setting up CFBuilder for debugging (http://www.carehart.org/presentations/), and I've done still others (also there) on using the debugger once you get it working. Fourth, I also did the chapter on the debugger in the recently published CF9 Web App Construction Kit book (Volume 2), which includes both configuration, use, and troubleshooting. Better news still, that chapter is one of 3 (out of the book's 20) that are in fact available online, in PDF form. More info (and a link to the PDF) at http://www.carehart.org/blog/client/index.cfm/2010/8/15/cfbuilder_debugger_CFWACK_chapter_online. That said, I don't recall seeing that exact error. I document several others in the resources above, so while I can't say you'll find the exact answer to your challenge there, again you may simply find some "aha" moment where something you configured just isn't quite right for your environment. All it would take is one setting out of place to keep it all from working. But many can and have gotten it working, and it can certainly be very valuable to be able to do interactive step debugging, so for most it's worth the effort to get it working. Last and finally, though, since you say you've messed with it for "hours", I realize you may not want to spend more time digging through docs, watching videos, etc. If you just want the problem solved ASAP, and are willing to pay for help, I do provide troubleshooting consulting as a service, via a shared desktop session (where I am "looking over your shoulders" using Adobe Connect). We should be able to get it working in short order. I'm afraid I can't offer that help for free, though. My usual consulting (focused on CF server troubleshooting) is offered at a rate of $175/hr. But I appreciate that fixing a server problem which affects your business may be more valuable (to most) than getting their development environment working. So I've been thinking about offering a specially priced option: $75 as a fixed price to help solve any one problem with CFBuilder (whether it took more or less than an hour, up to a max of 2 hours. If we couldn't solve it by then, there would be no charge.) Now, I appreciate that some may feel it's wrong to have to pay to get help getting their development environment working. I can't solve that problem (the fact that such help may be needed). But I'm sure Adobe is aware of the challenges people have and may be planning to address things in CFB 2. I give away the resources above to help with common challenges and get people started, but I'm willing to offer still more help to those who want it. I'll say as well that people have had problems similar to this going back to CF Studio in CF 4/5 (yes, there was CF debugging in that release, which we lost in 6 until its return in 8--unless one buys FusionDebug, which works in any release of CF from 6, forward.) So it's not really "new" to find it to be a challenge. Again, there are just lots of moving parts on the IDE and server ends (and sometimes communications in the middle.) I realize some will say "but it's not this hard doing debugging in other platforms". But note that in many languages, you're debugging a program that's running literally as a standalone process, accessed only by the debugger, if not literally running within the context of the debugger. CF apps are very different: they're running on the CF server, which is a separate process from the IDE (whether on the same box or not). And in fact (this may surprise many), it's not only "your own" requests to a page that can be debugged, but in fact any request by any user (if someone outside your box could request a page on your local CF server). So there's a lot more that goes on and goes into enabling debugging of CF apps. It's simply a somewhat complicated environment, setting it all up right. But as someone who has worked with debugging CF apps for 10 years, I've simply become attuned to the various details. I'm definitely NOT holding knowledge hostage. I give it away as mentioned above, but if someone needs help and has no aversion to paying for it (as from any provider of a service), I'm just saying I'm happy to help. /charlie ... View more

Thanks, Jochem. Yep, I do have a category for CF hosts there (one of over 125 categories of over 1,000 tools and resources for CFers). But I will note that I don't distinguish which hosts support different features. You'd have to investigate that, Bob. Sadly, I doubt any will promote the fact that they support Derby. Instead, I imagine it will be more like you'll be lucky to find one who does support it because they've updated their DSN automation mechanism to create Derby DBs. It's not outlandish to think a host might, if they want are inclined just to keep up with whatever CF offers. But as you're experiencing with CT, they may let it slip through the cracks. (It's also possible, though, that it could just "work", even if a host said they were not aware of it being supported. Worth a try, for anyone else in this situation of Bob's.) /charlie ... View more

Yes, that's right. while the default location is \root, that's really only because Adobe offers sample DBs and they had to put them somewhere. One creating a new Derby Embedded database can put it anywhere, so again this is more about the hosts being willing to update their automation mechanisms for adding new DSNs. And as Jochem rightly points out, some who propose to offer other things (support, backups, security) may feel that Derby is an unknown for them. /charlie ... View more

Wow, I think they're just confused. There's no option to enable/disable. It's definitely NOT limited to any OS. Derby is based on Java. In fact, for the past couple of years it's been bundled WITH java (as JavaDB, just a new name for the same engine). They may be thinking about the Derby Server version: that's where you start up a new server process to run the DB out of process from CF. Again, that's a built-in feature of CF. (One need not install anything if one DID want to use that option.) And to be clear, Derby is not new in CF9. It was added in CF8. It is by far a very poorly understood DB. I'm actually surprised no one has yet asked, "why do you want to even bother with Derby anyway? It's not a production database". Again, that's just not true. It IS intended for production use. And it is also NOT a single-user DB (as SQLite is), nor is it hamstrung for multi-threaded use as MS Access is. Still, one may wonder: why don't you just punt and use what your host offers? Is there anything about Derby you need? Is it perhaps because hosts may charge for adding DB's and you hoped that this might be free? That's not likely going to be so. In fact, part of the problem is that hosts DO often provide custom mechanisms to add new DSNs, and they may not yet have added support for adding Derby ones. Indeed, that leads nicely to Jochem's observation in the next message of the thread. I'll reply with a thought there. /charlie ... View more

Yes, he is mistaken. Derby is in fact embedded in CF 8 and 9 (Standard and Enterprise). There's nothing that he (or you) need to do to "enable it". It's enabled by default. You (and/or he) will find that the CF Admin DSN page offers Derby Embedded as a driver option. Point to it, and either use the checkbox there to say that you're creating a new DB, or place your DB files in the appropriate place in CF (\db\[dbname], by default), if moving them from another server. It's the latter which may trip up a host, if they're not prepared to make it easy/possible for you to put Derby files (the folder in which they are stored) into the appropriate location within CF that they are expected to be found. Very few people appreciate Derby and its value, especially hosts I suspect. You can point them to the CF docs. This is a documented feature. I also have done presentations on the topic (see http://www.carehart.org/presentations/) and articles (carehart.org/articles/), which could help and also point to still more resources. Hope that helps. /charlie Providing CF troubleshooting services at carehart.org/consulting charlie@carehart.org ... View more

OK, just did a little Googling for you about this, Josie (and others). There seem to be a few alternative solutions, each with pros and cons. The easiest, though, may be to simply use the 32-bit (instead of default 64bit) ODBC control panel, and then again use the MS Access driver in the CF Admin (not the ODBC socket one) to point to that. This is discussed here: http://www.cfexecute.com/post/access-dsns-in-64bit-coldfusion There's also a little more that may help at the bottom of this: http://www.zidsoft.com/x64.html MS also covers the topic here: http://msdn.microsoft.com/en-us/library/ms712362%28VS.85%29.aspx Other CF-specific solutions include: - run CF instead in 32-bit mode (even on the 64-bit machine). See discussion at http://www.houseoffusion.com/groups/cf-talk/thread.cfm/threadid:60467 - if you have 2 boxes available, you could run CF in 32-bit mode on one box (just for providing access to the 32-bit Access driver), then "proxy" the DSN setup from the 64-bit CF machine to access the DSN on the 32-bit machine (See http://www.coldfusionmuse.com/index.cfm/2009/4/7/MS.Access.Proxy) - get an alternative jdbc driver for Access (HXTT), mentioned in the threads above - did you happen to try the "microsoft access with Unicode" driver option in the CFAdmin? That is quite different from the one that is not "with Unicode", so worth a try if nothing else works for you. Let us know if any of these suit you. Also, I appreciate the annoyance of those who would think this should "just work" without workarounds. I think I have clarification there. First, the CF9 System Requirements page is unclear on this. While its systems support matrix lists 32 and 64 but windows (among others), those don't list what DBs are supported on each. Instead, there's a database support matrix at the bottom, which does indicate that Access is supported, but it doesn't break it down per OS, let alone bit-level of each OS. But I just found a clarificaiton in a devnet article (by an Adobe engineer) that does seem to put the nail in the coffin: "Most of the functionality and features of ColdFusion run just fine on 64-bit platforms, however, certain features like ColdFusion COM interoperability, ColdFusion Delphi interoperability, and Microsoft Access database connectivity do not work on a ColdFusion 64-bit platform. A few other features, such as ColdFusion .NET integration services and database drivers currently run in 32-bit mode." (http://www.adobe.com/devnet/coldfusion/articles/64_bit_print.html) I think most haven't noticed this or made much of it simply because Access has been eschewed by so many for so long. /charlie Providing CF troubleshooting services at carehart.org/consulting charlie@carehart.org ... View more

Are you sure it's 90 minutes? Could it be instead every 67 minutes? That's a specific and important mark: it's the default time for "client variable purge" to take place. (of course, you may well have changed it to happen every 90 minutes instead). See the CF Admin, Client Variables page, and its "purge interval" setting. I won't elaborate on this until you confirm if it may be the issue. I'll note as well that the clock for this starts with the start of CF (so 67 minus into the run it will do the first purge, repeating every 67 minutes thereafter). You can confirm the exact time that the purge happens by viewing the \runtime\logs /charlie Providing CF troubleshooting services at carehart.org/consulting charlie@carehart.org ... View more

alazzaro27, you probably ought to create a new forum thread for your issue, since your problem (CF hanging at startup) really has nothing to do with perfmon values being reported as "crazy numbers" as ciaranarcher reported in the original message. Anyway, there can be dozens of reasons that you may find that CF hangs on starting (or while processing). I appreciate that you're frustrated, but I'm afraid you can't just scream "please, please, please FIX!!!" and expect your problem to be solved. You simply need to analyze diagnostic information you have (or enable more) and identify and resolve whatever is wrong. Problems with CF Server performance/reliability can always be resolved, if you attack the problem methodically. There are a few different resources of diagnostic information available, some built-in (and not obvious), others that need to be enabled. I've given many presentations that outline various tools and techniques, as well as resolutions to various problems, available online at my site, http://www.carehart.org/presentations/. Look for the ones prefixed "CF911". If you want to review some of those and report back here with more info, perhaps we can help. (Again, it may be best to start a new thread.) In particular, you'll want to check out what info may be reported in the \runtime\logs (or \logs if on multiserver). Those can be key to identifying what's amiss. If there's no info there, then it may be valuable instead to use a tool to report what's happening at the time of a seeming hang, whether the CF Server Monitor if you're on CF 8 or 9 Enterprise, or a tool like FusionReactor or SeeFusion if on CF 6-9 Standard or Enterprise (both come with free trials). Even so, when you're exasperated and frustrated (as it sounds like you are), then it can be difficult to understand how best to use these tools, and how to interpret the various info they provide. That's where it can be more effective to bring in someone to help. Sure, forums like this are a great way to get free help, but sometimes it's hard to resolve via back and forth over email (and with delays in response, it can take days). Some problems are just better solved by having someone "look over your shoulder" on a shared desktop session (like Adobe Connect). Some of us provide just that sort of support. If it interests you, check out http://www.carehart.org/consulting, or a list of still other such folks I keep at http://www.cf411.com/#cfassist. I'm sensitive to the concern that some may think this last paragraph is a sales pitch, which is why I offer the list of other folks as well. I (and others) share free resources, as above, and happily interact here to help if we can. But if you're in a hurry to get this solved, and especially if it's affecting your business, I'm just sharing other alternatives. /charlie ... View more

Fair enough. Though let's be clear: I've been referring specifically to the cfclasses directory (though both Mike and I relaxed and referred to it as "classes"). To be clear, in case it will help anyone (as it can indeed fill with files), we're talking about \wwwroot\WEB-INF\cfclasses. I can think of another, perhaps, that could fill with files perhaps unexpectedly: the \cache directory, where CFCACHE content is stored, and never removed, as far as I can recall. But that's not really "deep". Now, we should also clarify that in the multiserver mode of deployment (multiple instances), then even these normally "high level" directories are indeed now buried deep. For instance, the cfclasses would be in: \servers\instancename\cfusion.ear\cfusion.war\WEB-INF\cfclasses (where the .'s are -'s in the case of the "cfusion" instancename) And the cache would be even further down, in: \servers\instance2\cfusion.ear\cfusion.war\WEB-INF\cfusion\cache Anyway, this is where a tool like to analyze the size or count of files in your directory structure can help. A classic in this space is Treesize, a free tool for Windows at http://www.jam-software.com/treesize_free/. There are others and for other OS's, of course. Again, though, my proposal to use the free processmonitor tool could also help in identifying high rates of I/O happening while the server is running, or starting as in Mike's case. He may not have a "high number of files" like you do, ilssac, but instead just may have a high rate of file use. And Mike, is it really just "starting" CF that gradually slows? Or all of CF? If the latter, I would suspect yet another possible explanation: client variables. Even if you don't "use them", if you enable them (with ClientManagement in cfapplication or in the this scope of application.cfc), then by default CF will write to the client variable repository on every page visit to any application that enables them. The default store is the registry, but even if you change that to a database, it could still be a problem, which would grow over time. /charlie ... View more

Mike, have you looked at and found anything informative in the \runtime\logs (note that I DO NOT mean the \logs)? There is additional info about the goings on in CF, especially around startup/shutdown, that could give you more insight into what's amiss. Beyond that, and piggy backing on ilssac's observation, if I were in your shoes I would enable a tool like ProcessMonitor (a free tool from the sysinternals group at Microsoft), to view what I/O is happening on behalf of CF. It could be that CF is doing some reading or writing of files in a directory that's become very large, and choosing to use a new user may cause it to do that in a new directory. (I realize that you said that you cleared the classes folder, which is probably what ilssac was referring to. I'm wondering if may be something else.) Just beware that you don’t' want to leave the ProcMon tool on for very long (like more than 10-20 seconds) because it does gather up a LOT of info--you'd be amazed how much I/O happens on your machine, both in and outside of CF. I will add that if the problem remains I would welcome the chance to help you resolve this. I love challenges like this. And while you may feel that you've paid enough people to try help you , I'll note that I have a satisfaction guarantee: if you don't feel that some portion (or even all) of the time I spend with you is valuable, then I don't want to get paid for it. More at http://www.carehart.org/consulting/. Pardon the sales pitch, to those sensitive to that. I try to give free advice often here. Sometimes, though, certain problems just can't be easily resolved over email (and when doing a shared desktop session with a phone call is much more effective.) Also, for some people, paying for help for a critical problem is not at all distasteful, so I'm just sharing an option. /charlie ... View more

Well, before offering another thought on things, a key question needs to be asked: Why are you using ODBC at all? You're on CF Enterprise. There are native drivers for SQL Server and Sybase, and a dedicated driver for Access. I do realize that some people started using them back in the day (CF 3, 4, or 5) and maybe never bothered to stop using them when JDBC drivers came out with CF 6. Or perhaps you recently jumped from 5 or earlier to 9. So the first thought is: don't use ODBC if you don't have to. Is there anything, given that, which would still compel you to press on? (If so, I have more thoughts for you below.) But let me digress for a moment and say, for the benefit of someone else reading this someday, who may be on CF Standard: even in CF standard, there are at least dedicated (non ODBC) drivers for SQL Server and Access. As for Sybase, you could perhaps still want to try to connect to it using ODBC, but I'll note that one could get a free JDBC driver for Sybase (such as at http://jtds.sourceforge.net/) and use the "Other" driver type when setting up the datasource in CF. Back to your problem at hand, if for some reason you want to press on, besides what Ian offers, I'll ask this: did you by any chance have CF 8 (32 bit) installed on the box before upgrading to CF 9 64 bit? It's just a guess, but I could see that if the ODBC services remained from the old install, it could cause confusion. /charlie ... View more

So to be clear, if you are accessing the Admin using the Instance Manager, then you will notice when the pages open (in the Admin for the other instances) that they use a port, like 8301. That's the internal web server, and therefore you ARE NOT using IIS to access the CF Admin for anything but your cfusion instance. I only pressed that because if you WERE saying you were accessing the Admin for each instance via IIS, then it would have been very odd if you didn't experience the same in connecting to your app via IIS. As for your saying that "we created the other two sites by manually editing the applicationhost.config file and copying the configuration from the first site and changing names", wow that's indeed important information. There's more that the web server config tool does than just to the config IIS for the site. It also creates the needed files in the CF installation, so you can't "just modify" the IIS side of things. You say also that you have "tried removing/readding the configuration with wsconfig". Was that separate from your manual steps above? I would recommend that you do that, and not do any monkeying around with things in the IIS config, and make sure it works (without regard to worrying about replicating your needed virtual directories). If it does, THEN you can do whatever you want on the IIS side. (And I'm also still not convinced that the changes to applicationhost.config are what you need. I've never seen mention of that, though I realize IIS 7 is quite different. I did what editing I needed to do to get things working when I needed to do them manually in IIS by modifying the interface. Are you positive 100% that that file (and only that file) is what gets modified corresponding to changes in the IIS interface. If you're not 100% sure, then you may be doing only half the job, which could explain why things aren't quite working for you.) Whenever you set out to do things manually, to save time, you run the risk of things not working as expected. And with IIS 7 support for CF being so new, you're running at even greater peril for there being fewer people available to help share experience with applying the same tricks--and avoiding important traps. /charlie ... View more

Well that stinks: I just viewed this message from earlier as it appears within the forum, and I see that the code fragment I offered was dropped somehow. I had replied via email. I had not ever noticed that these forums did not allow HTML/CFML in messages sent by email. The code I had offered (without the opening/closing brackets) was this: cfoutput Instance name: #createObject("java", "jrunx.kernel.JRun").getServerName()# /cfoutput ---------------------------------------------- Here's the message from earlier in this thread that I'm referring to. I had said: You could identify the instance with this code: (Someone  might also propose running the CF Admin to see what it would report,  but the default in multiserver mode is to access the Admin via the  built-in web server, not IIS, so unless you take extra steps to enable  that, you may not be able to access the Admin via IIS against each site  separately. You could call the Admin API to get various information as  it would be reported in the Admin, but the above is an "old school"  pre-Admin API way of getting the info.) /charlie ... View more

But wait, you're saying here that you have "one CFADmin site". I was referring to accessing the CFAdmin for each instance. What instance does that one CFAdmin site go to? And how do you access then the CFAdmin's for each instance? As for sites 2 and 3 getting "defaulted to #2", I will assert again that you need to remove the config for sites 2 and 3 and create them again. For some reason, though the dirs exist (you say, for 2 and 3), they are not being pointed to by IIS. Correction of that within the web server config tool should fix that. As for a change to one handler mapping causing a change in the others, that doesn’t really make sense at all. Each site (within IIS) is distinct from the other. I'm not aware of there being any connection of all this to applicationhost.config. (Not that there may not be one: I just don't know of it.) /charlie ... View more

But are you accessing the Admin using the built-in web server? That would be very different and not related to IIS. And what do you mean "assigns it a different number"? Are you referring here to the port for the Admin, such as 8301, 8302, or the number within the IIS wildcard mapping you referred to previously? And if the latter, what you do mean "always assigns a different number"? I thought you were saying before that it reverts back to some one number despite your changing it. Do you now mean that it really changes somehow to a new number (on a CF restart)? That would be very odd. You also didn't answer if it's a restart of CF that you were referring to in the first note. Just trying to help. Please don't take any offense in my pressing these points. /charlie ... View more

You could identify the instance with this code: (Someone might also propose running the CF Admin to see what it would report, but the default in multiserver mode is to access the Admin via the built-in web server, not IIS, so unless you take extra steps to enable that, you may not be able to access the Admin via IIS against each site separately. You could call the Admin API to get various information as it would be reported in the Admin, but the above is an "old school" pre-Admin API way of getting the info.) /charlie ... View more

You don't say, but is this IIS 7? If so, the main problem is that CF8 did not support it. Indeed, neither did CF9, until formal support was added in 9.0.1, which is perhaps why you've had the good result there. To be clear, one could struggle to get CF 8 and 9 to work on IIS 7, but the point is that it's not point and click simple as with CF 9.0.1. Most important for getting older releases to work is to enable isapi extension and IIS 6 compatibility (again, not needed for 9.0.1). There are various people who have written about trying to get releases prior to 9.0.1 to work with IIS 7. Check out: http://www.codecurry.com/2009/09/installing-coldfusion-on-iis-7.html http://blog.kukiel.net/2009/07/installing-coldfusion-8-9-on-vista-and.html http://dale.fraser.id.au/2008/05/coldfusion-8-vista-sp1-solution.html The following even talks about it from the CF7 timeframe: http://www.communitymx.com/content/article.cfm?cid=224AA&print=true Let us know if that helps. /charlie ... View more