embeded derby as client variable store

[ToBeNamedLater]

I've spent considerable time trying to configure the built-in derby embeded DB as a CF client variable store and have failed utterly. It seems to be impossible.

I had a SQL Server client store which worked just find, but, for various reasons that are irrelevant here, I would really prefer not to do that and use derby instead.

I created the database, created the dsn, set the dsn as the client store and it all looked okay. But it isn't. The CLOCAL and CGLOBAL tables were not created as they should have been (and were for SQL Server). So I created them by hand as described in the help files, but that failed as well. Changing various things yields different errors, but there is a consisted 500 Server error. I can only guess that the database writes are failing, but there is no indication as to why.

I have looked all over adobe.com and all over the intertubes and there is no further information of any kind. In fact, the latest instructions for even creating the database date back to May 2007 and have no resemblance to the administrators screens at all. (I'm running CF 8,0,1,195765 standard). When I create an embedded derby dsn, I get the generic "default" Data & Services > Datasources > Other screen. There's nothing "derby" about it.

So, frankly, it seems pretty pointless and useless to me. If someone can point me DIRECTLY to relevant information, I'd appreciate it. I cannot believe in the year plus this product has been out that NO ONE has done this, especially when it's commented all over the place that this is one of the things you can do, yet there's nothing. Even searching for just "derby" on these forums yields only three hits, none of which are relevant.

[Newsgroup_User]

> I've spent considerable time trying to configure the built-in derby embeded DB
> as a CF client variable store and have failed utterly. It seems to be
> impossible.

It's not impossible. I followed through the gist of what you said you'd
tried, and it worked fine for me. This doesn't help you much, I know, but
it confirms it is possible. And confirms the source of your problems might
be a bit closer to where you're sitting than you suggest they might be ;-)


> I created the database, created the dsn, set the dsn as the client store and
> it all looked okay. But it isn't. The CLOCAL and CGLOBAL tables were not
> created as they should have been (and were for SQL Server).

Well it does actually *tell you* it won't create them automatically when
you go to set the DSN as the client store. I suppose one has to read what
it says on the screen, which I have to say I don't bother doing a lot of
the time in CFAdmin because I "know" what the text says. This very screen
has caught me out with that before. Just the first time, though.


> So I created them
> by hand as described in the
> http://livedocs.adobe.com/coldfusion/8/htmldocs/help.html?content=sharedVars_08.
> html,

What were the exact statements you ran to create the tables & indexes?


> Changing various things yields different errors,

What are the error messages?


> 8,0,1,195765 standard). When I create an embedded derby dsn, I get the generic
> "default" Data & Services > Datasources > Other screen. There's nothing
> "derby" about it.

That sounds wrong. I get " Data & Services > Datasources > Apache Derby
Embedded" on all three servers I have at my disposal currently (a mix of
CF8 multiserver, CF8 stand-alone), and the rest of the screen is
Derby-specific. It sounds to me like your install is bung. Are you saying
when you select "Apache Derby Embedded" you just get the same screen you
would have had you selected "other"? Odd.


> So, frankly, it seems pretty pointless and useless to me.

Well, I suppose that's one way of looking at it. But quite a
counterproductive one, and one that's not likely to get you too far. It's
not CF's or Derby's fault something is bung with your install, is it?


> If someone can point
> me DIRECTLY to relevant information, I'd appreciate it.

You've got all the relevant info you need. The only variation to the
normal instructions for setting up a DSN for client variables is that one
has to create the relevant tables. And to do that, all I did was to copy
the script from that URL that has the table-create statements on it, and
change the Acccess-specific data-types to Derby-specific ones: memo->clob,
date->timestamp.

However if you're not getting the right screen when trying to add the DSN
in the first place, I think you'd better try to sort that out first.


> I cannot believe in the
> year plus this product has been out that NO ONE has done this,

I think your problem here is your attitude that because *you* can't make
something work then automatically nor can anyone else. That is seldom
going to be the case, surely (or you lead a very charmed life). I always
find that when something doesn't work for me in CF it's almost always my
fault.


> is one of the things you can do, yet there's nothing. Even searching for just
> "derby" on these forums yields only three hits, none of which are relevant.

Oh, the search on these forums is rubbish, so don't put too much stock in
that. You're better off using Google Groups to search these forums.

That said, if there's not much discussion on people having this sort of
problem, it's probably because they haven't *had* these problems. Which in
turn points even more towards the odds are that you're doing something
wrong.

So... can you please clarify what you said about getting the "other" DSN
screen, and also clarify how you created the Derby DB, and what your
table-create statements were. Also what those errors are that you're
getting. Then we can work out how to get you sorted.

--
Adam

[ToBeNamedLater]

> Well it does actually *tell you* it won't create them automatically when
> you go to set the DSN as the client store. I suppose one has to read what
> it says on the screen, which I have to say I don't bother doing a lot of
> the time in CFAdmin because I "know" what the text says. This very screen
> has caught me out with that before. Just the first time, though.

Actually, it does not tell you. The SQL Server screen presents you with a box that says "create tables" but this one does not. There's no mention whether it does or whether it does not. Consequently, it does not but it says nothing at all. I'm very good at reading.

> What were the exact statements you ran to create the tables & indexes?

The ones you expect. And the tables are there and created correctly as per <cfdbinfo> which matches the <cfdbinfo> created by CF in SQL Server. Things like:
CREATE TABLE CDATA (cfid char (64), app char (64), data clob,)
CREATE TABLE CGLOBAL (cfid char (64), data clob, lvisit datetime)
CREATE UNIQUE INDEX id1 ON CDATA(cfid, app)
CREATE INDEX id2 ON CGLOBAL(cfid)
CREATE INDEX id3 ON CGLOBAL(lvisit)

> What are the error messages?

As I said, the only consistent one is an Apache 500 Server error

> That sounds wrong. I get " Data & Services > Datasources > Apache Derby
> Embedded" on all three servers I have at my disposal currently (a mix of
> CF8 multiserver, CF8 stand-alone), and the rest of the screen is
> Derby-specific. It sounds to me like your install is bung. Are you saying
> when you select "Apache Derby Embedded" you just get the same screen you
> would have had you selected "other"? Odd.

Also, as I said, I do not get any Derby anything. I get the default, generic "other" jdbc data source creation screen, In fact, I even copied the derby-specific URL from the create link and pasted it into the browser, and CF Admin redirected it to the generic jdbc. This happens on all three CF servers I have access to (all running 8.0.1 standard).

> I think your problem here is your attitude that because *you* can't make
> something work then automatically nor can anyone else. That is seldom
> going to be the case, surely (or you lead a very charmed life). I always
> find that when something doesn't work for me in CF it's almost always my
> fault.

Thank you for your opinion. It's most helpful and is what makes these forum the final last resort I turn to when all else fails. I suppose I should have assumed that, absent all indications, that indicates it's a silent CF failure I should have somehow psychically determined. If you read for comprehension you'll see that I said I can't believe no one had done it. If found several places that said "it should be possible" but that no one had actually done it. Perhaps you can show me where someone says they have. Google wasn't able to. Not web, not groups, not adobe.com.

> Oh, the search on these forums is rubbish, so don't put too much stock in
> that. You're better off using Google Groups to search these forums.

Ah! It doesn't work. How, exactly, should I have known that? I did search Google groups. And Google Co-op. And Yahoo. And MSN. And ixquick.

> That said, if there's not much discussion on people having this sort of
> problem, it's probably because they haven't *had* these problems. Which in
> turn points even more towards the odds are that you're doing something
> wrong.

As I said the first time and again above, and will repeat again here: I can't find anywhere where someone said they've actually done it. People say 'you should be able to' no one has that I can find. So I assumed no one has. If no one's done it, how, exactly, could they have had a problem. Maybe it didn't work for them either and they gave up. I say again, the derby DSN creation silently redirects to the generic jdbc create. No error: nothing.

And, as it's framed, you can't see the URL at all, so it wasn't even immediately clear I was being redirected. It took a while to even realize that. And since the searches all returned to me things that were written in early 2007, well before the final CF8 release, I figured Adobe changed their minds and did it differently in the released version []i]since they've done exactly that dozens of times in the past.

[Newsgroup_User]

>> Well it does actually *tell you* it won't create them automatically when
> > you go to set the DSN as the client store. I suppose one has to read what
> > it says on the screen, which I have to say I don't bother doing a lot of
> > the time in CFAdmin because I "know" what the text says. This very screen
> > has caught me out with that before. Just the first time, though.
>
> Actually, it does not tell you. The SQL Server screen presents you with a box
> that says "create tables" but this one does not.

It doesn't say - underneath the "Description" text area "Your data source
requires you to manually create the necessary database tables to store your
client variables. See the Online Help for details. "?

It does for me.

You have a most curious CF install, and I would be very hesitant continuing
with it given what you say.

What OS are you running on? Do you still have your install logs, and do
they reveal anything relevant?

Is this an install that was fresh 8.0 (or 8.0.1), or has it been upgraded
from an earlier release?


> The ones you expect. And the tables are there and created correctly as per
> <cfdbinfo> which matches the <cfdbinfo> created by CF in SQL Server. Things
> like:
> CREATE TABLE CDATA (cfid char (64), app char (64), data clob,)
> CREATE TABLE CGLOBAL (cfid char (64), data clob, lvisit datetime)
> CREATE UNIQUE INDEX id1 ON CDATA(cfid, app)
> CREATE INDEX id2 ON CGLOBAL(cfid)
> CREATE INDEX id3 ON CGLOBAL(lvisit)

OK, that sounds about right. The only thing I did different was to use
timestamp rather than datetime. I'm not sure if that's worth a try.

Can you insert / update / delete manually to/from those?


> > What are the error messages?
> As I said, the only consistent one is an Apache 500 Server error

The inconsistent ones would probably be helpful to know about too.

What goes into the CF logs when these errors are being raised? Do the 500
errors give an stack trace info? I think 500 errors usually don't, but
don't exactly recall.


> > That sounds wrong. I get " Data & Services > Datasources > Apache Derby
> > Embedded" on all three servers I have at my disposal currently (a mix of
> > CF8 multiserver, CF8 stand-alone), and the rest of the screen is
> > Derby-specific. It sounds to me like your install is bung. Are you saying
> > when you select "Apache Derby Embedded" you just get the same screen you
> > would have had you selected "other"? Odd.
>
> Also, as I said, I do not get any Derby anything.

I'm finding your tone a bit tedious to be honest.

I asked for clarification because you weren't completely clear in your
post, and I just wanted to make sure you were sure what you were seeing
because it's somewhat unusual to be getting completely the wrong screens in
CFAdmin. In all the CF servers I have had responsibility for, I've not
seen this, so I just wanted to *make sure* I was reading you right.


> "other" jdbc data source creation screen, In fact, I even copied the
> derby-specific URL from the create link and pasted it into the browser, and CF
> Admin redirected it to the generic jdbc. This happens on all three CF servers I
> have access to (all running 8.0.1 standard).

Weird. How did you create the Derby DBs themselves? It's usually one of
the options on the create DSN screen. Did you create them manually or
using some other client tool?


> > I think your problem here is your attitude that because *you* can't make
> > something work then automatically nor can anyone else. That is seldom
> > going to be the case, surely (or you lead a very charmed life). I always
> > find that when something doesn't work for me in CF it's almost always my
> > fault.
>
> Thank you for your opinion. It's most helpful

When trying to solve a problem that's a result of something you've done, I
find it easy to take the mindset that *you've* done something wrong, not
[something else] has done something wrong. Once one starts looking more
analytically at one's own actions, sometimes a flag comes up, and there's a
bit of a "slap forehead" moment. However if it's predetermined that
something else is at fault and one is just the victim of circumstance, it's
difficult to progress.

It's just better to dispense with the hand-wringing and roll up the sleeves
and get on with fixing it.


> should have somehow psychically determined. If you read for comprehension
> you'll see that I said I can't believe no one had done it.

Have you not found anyone reporting to have used the Derby DB? I have to
say that I'd never used it before y/day, because I've got the luxury of
having Oracle or SQL Server DBs at my disposal. However I do know of other
organisations using Derby for their demo DBs, and have read a few things
about its usage.

I don't think you should expect to hear people reporting back "hey I am
using Derby to store my client variables", because I don't think it's
really that report-worthy. How many people to you see reporting back "I'm
using my Oracle DB to store client variables"? As "storing client
variables in a DB" is such a mundane thing, people are only going to report
on it if they have had problems with it. Maybe no-one's done it (except
for me, as of y/day). Maybe no-one's had a problem with it. A case in
point: I had no problems setting it up, so I have no further need to report
anything to anyone about it because it's "job done, move on".


> As I said the first time and again above, and will repeat again here: I can't
> find anywhere where someone said they've actually done it.

I've *actually done it*. I told you this y/day, as soon as you asked.

There you go. Can we move on now please?

I'm not actually sure you want help, but if you do, follow up with those
error message and anything from the logs that are helpful. I think you
just want to have a moan as to how you've been so put upon, and if that's
the case, I think we're done here. It's up to you as to how to proceed.

--
Adam

[Newsgroup_User]

> (all running 8.0.1 standard)

One other potential differnce between your rig and mine is that I'm running
the latest hotifx pack ( http://www.adobe.com/go/kb403622). Are you? None
of the things they claim to have fixed are relevant, but I've found in the
past that not everything they've fixed is mentioned. That said, I'm sure
if there was actualyl a problem with CF itself, other people would have
raised similar issues.

--
Adam

[ToBeNamedLater]

> It doesn't say - underneath the "Description" text area "Your data source
> requires you to manually create the necessary database tables to store your
> client variables. See the Online Help for details. "?

No, it does not say that.

> You have a most curious CF install, and I would be very hesitant continuing
> with it given what you say.

Hence my frustration. But it's been running for over a year (or from whenever 8 was released). The only other problem I've had is the Verity collections did not install correctly on my system, but was fixed with instruction from a KB, as, apparently, it's a not-uncommon problem.

> What OS are you running on? Do you still have your install logs, and do
> they reveal anything relevant?

We have three systems.
Mine (dev): XP SP 2
Client1 (dev): 2000
Client2 (prod) 2000

> Is this an install that was fresh 8.0 (or 8.0.1), or has it been upgraded
> from an earlier release?

Mine and Client2 are upgraded from CF7 -> CF8 -> CF8.0.1 (with 8.0.1 cumulative hotfix)
Client1 is a clean 8.0.1 (with hotfix) install
All three behave the same way. Per your second post, I did have the cumulative hotfix installed, but I reinstalled it again.

> OK, that sounds about right. The only thing I did different was to use
> timestamp rather than datetime. I'm not sure if that's worth a try.

Actually, on re-reading my notes, I did use timestamp as there is no "datetime" data type in derby. (I use datetime in sql server since timestamp is not a timestamp in sqlserver which led me to misspeak.)

> Can you insert / update / delete manually to/from those?

Yes.

> The inconsistent ones would probably be helpful to know about too.

Leaving CFAdmin Client Variables set to "None" and specifying
<cfapplication clientmanagement="yes" clientStorage="ClientVariables" ...
yields
The datasource named ClientVariables is not a valid client storage DSN.
Define client storage DSN through the ColdFusion Administrator.

Defining the the DSN in the administrator with the same cfapplication settings (which should be redundant) yields

Holy crap, it worked! Hmm ... what's the difference from now to yesterday ...... Nothing. I recorded all the steps yesterday and re-created them again this morning. This makes me very confused and uncomfortable. Removing the
clientStorage="ClientVariables"
from <cfapplication works as well. It didn't work yesterday.

But to continue with your questions:

> How did you create the Derby DBs themselves? It's usually one of
> the options on the create DSN screen. Did you create them manually or
> using some other client tool?

I created the DB using the Data & Services > Datasources > Other screen but specifying in the jdbc URL field:
jdbc:derby:C:\ColdFusion8\db\clientvariables;create=true
then changing it back to create=false

The tables were created using <cfquery ...

> Have you not found anyone reporting to have used the Derby DB?

No, I have not.

So, thanks. The problem has been fixed/worked around if not solved. Clicking "create derby datasource" still takes me (and all the other systems) to the generic jdbc / other which, from your description, is wrong. But client variables now seem to be working even if I can't figure out why.

[Newsgroup_User]

Well it's good you got there in the end. Just one last thing to say:

>> It doesn't say - underneath the "Description" text area "Your data source
> > requires you to manually create the necessary database tables to store your
> > client variables. See the Online Help for details. "?
>
> No, it does not say that.
>
> > You have a most curious CF install, and I would be very hesitant continuing
> > with it given what you say.
>
> Hence my frustration. But it's been running for over a year (or from whenever
> 8 was released). The only other problem I've had is the Verity collections did
> not install correctly on my system, but was fixed with instruction from a KB,
> as, apparently, it's a not-uncommon problem.

Yeah, I've had problems with Verity as well. I'm kinda used to
re-installing it every couple of months.

One thing. All these installs... did they all come from the same installer
file (ie: the one you D/Led from the Adobe website)? If so, what's the
size of the file in bytes?

My Coldfusion-8-win.exe file is 343,205,536 bytes; coldfusion-801-win.exe
is 393,019,680 bytes.

I have known in the past for Adobe (although probably Macromedia @ the
time) to put up slightly bung installer downloads, which later get fixed.

If I were you, I'd probably live with my dev box being "weird", but I'd
have serious apprehensions about the live boxes not running exactly as they
ought to.

If you've got the resources (available kit, time), D/L 8.0.1 again, and try
a fresh install to see what you get...

--
Adam

[ToBeNamedLater]

> One thing. All these installs... did they all come from the same installer
> file (ie: the one you D/Led from the Adobe website)? If so, what's the
> size of the file in bytes?

> My Coldfusion-8-win.exe file is 343,205,536 bytes; coldfusion-801-win.exe
> is 393,019,680 bytes.

I'm not sure I can answer that. I have CF8 in a box, but I really don't remember if I installed it from there or from a download. The updater I installed from a download:

coldfusion-801-win_updater.exe 137,178,880 bytes, 04-Apr-08

I believe my client did the same, at least for the live system. Client's dev system had a catastrophic failure and was rebuilt using only the 801 from download. But all three behave the same way.

> I have known in the past for Adobe (although probably Macromedia @ the
> time) to put up slightly bung installer downloads, which later get fixed.

Wonderful. Very professional.

> If I were you, I'd probably live with my dev box being "weird", but I'd
> have serious apprehensions about the live boxes not running exactly as they
> ought to.

The live system is less of an issue, frankly. Client has MS SQL Server and I've set that up to be the client store for them. I, however, do not want to buy and install SQL Server for myself just for a client store, but I'm now supporting so many projects and clients, that registry/cookie client variables isn't practical. I also have limited ability to tell the client's IT department what to do. I can only recommend, and since they aren't using derby, the likelihood of my being able to convince them to throw any resources at this is very limited since it's not a function they use. We're all stretched to the breaking point as it is (as is everyone else). I'm having enough trouble trying to convince them to use a grown-up e-mail system.

> If you've got the resources (available kit, time), D/L 8.0.1 again, and try
> a fresh install to see what you get...

I will try again on my own dev system as soon as I can, but that may not be for a few months as the thing is now working.

Thanks for your help and advice.

[Newsgroup_User]

> > I have known in the past for Adobe (although probably Macromedia @ the
> > time) to put up slightly bung installer downloads, which later get fixed.
>
> Wonderful. Very professional.

People make mistakes. The bods at Adobe are just people.


> The live system is less of an issue, frankly. Client has MS SQL Server and

Of course, yeah. Sorry, forgot this is just a work around for the dev
environment.


> I've set that up to be the client store for them. I, however, do not want to
> buy and install SQL Server

You know SQL Server Express is free, right?

That said, I think using Derby for client vars is perhaps better solution
(now than it's working).

But if you need to use SQL Server for dev work, don't forget about SQL
Server Express. It's the same engine as SQL Server, just throttled. I
also think some high-end data-warehousing & reporting stuff is missing, but
that's not likely to be an issue for most web apps, I should think.


> > If you've got the resources (available kit, time), D/L 8.0.1 again, and try
> > a fresh install to see what you get...
>
> I will try again on my own dev system as soon as I can, but that may not be
> for a few months as the thing is now working.
>
> Thanks for your help and advice.

NP. Am pleased you got there in the end.

--
Adam

[ToBeNamedLater]

> People make mistakes. The bods at Adobe are just people.

My issue isn't with the mistake. I make them too. But when I make them, I announce that there's a problem with XYZ and they need to patch or replace it with ABC. I don't just slipstream a "fix" in with no announcement and pretend like it never happened then make out like it's a user error. I mean even device driver people will release a 8.0.1a. Comparing dates and file sizes is Just. Plain. Wrong.

> You know SQL Server Express is free, right?

Yes, but that's not really the issue. SQL Server in any incarnation is a fairly greedy memory hog that I'd rather not have installed on the CF Server. Buying another box to just to store client variables is just crazy. (My client development uses the client's SQL Server at their site, so I don't need one.) My CF server is also running Openfire and AVG which are both pretty greedy as well. If I ever do need the SQL Server, I do have a copy from attending that release event thing last spring, but it's still sitting here in the box along with Visual Studio and Vista and whatever else it came with.

[Charlie Arehart]

I can clear up the confusion. It turns out this issue of you being taken to the Other DSN page when you add a Derby Embedded DSN is a bug in CF 8 Standard.

That's why you weren't seeing it, Adam, and really, many people have gone around a lot on this issue.

I can definitively confirm it's an issue that happens only on CF 8 Standard, and I just blogged about it:

http://www.carehart.org/blog/client/index.cfm/2009/3/2/bug_with_derby_on_cf8_standard

Hope that's helpful. I've not read every word of the rest of the discussion above, but if there are any other outstanding questions I can answer, I will try. Just wanted to offer this ASAP.

[ToBeNamedLater]

> I can clear up the confusion. It turns out this issue of you being taken to the Other DSN page when you add a Derby Embedded DSN is a bug in CF 8 Standard.

Ah. I should have known. I don't suppose this known bug in a product that has been out for a year or more is actually written down anywhere a mere mortal can find it?

It's stuff like this that makes it harder and harder for me to keep clients from kicking CF to the curb.

Anyway, thanks for the confirmation.

[Newsgroup_User]

> It's stuff like this that makes it harder and harder for me to keep clients
> from kicking CF to the curb.

Stuff like: "you had a problem, raised it with the community, and within 19
hours - during which time every post you made was responded to in a timely
fashion - the community had stumped up and helped you get it sorted?"

Yeah: screw *that*.

--
Adam

[ToBeNamedLater]

You're taking the wrong lesson again. My objection is to slipstreaming in fixes silently. I can't sell that to my client and it makes it harder and harder to advocate for CF. I spend a significant amount of time fending of Tomcat and ASP.net. I've even got people here promising to re-write existing apps for free if they'd dump CF (and, by extension, me). It's hard to deal with that when Adobe pulls stunts like those you describe.

I appreciate all the help I got here. I have to say I'm impressed. It's an experience I've never had here in the past which has always made this place the one of last resort. Every time in the past, the response has been "RTFM" even though I've always R'd the FM before coming here. I'm happy that this time it was different, and I've thanked you for that. I will do it again: thank you.

I also note that the problem turned out to be not something I was doing, but a bug in the product apparently known to at least a few of the cabal. I did search, as I said. I searced the web, groups, and adobe.com (kb, forums, support: everything). I found nothing. Wouldn't you think it would be listed somewhere as "known issue"?

Again: thank you.

This thread is closed.

[Charlie Arehart]

You seem to have come to some inaccurate conclusions and are making some wild assertions. I don't myself like to contribute to (or participate in) flame wars but in this case I want to step in to again try to offer some moderating comments.

I know you've been beefing with Adam to this point, but after an answer is offered (which you seem to accept) you call it "a bug in the product apparently known to at least a few of the cabal". Eh?

It's not been known to anyone, that I can gather. That's why I added that I'd blogged about it just today. Some context may help:

I've been following the integration of CF and Derby since its release, probably closer than anyone else. I've heard of these problems, of people experiencing the curious redirect you did, but no one had ever sorted it out that I know of, until today. So there's no "cabal" that's keeping info from you, or others.

Now, you have a reasonable beef that the bug has festered this long, but really, rather than use it to make another "see, this is why CF sucks" kind of argument, let's just recognize it for what it is: a new and rather misunderstood feature (Derby in CF), and a bug in the Admin found only in a version (Standard) that can't be confirmed except by those who own a Standard license.

I'd wager that most people use the Developer edition for their day to day work with CF, since it's free. They may deploy onto Std or Ent, but they don't likely develop on Std. And this bug could never be recreated in the Dev or Ent version. You have to own (and pay for) a Standard license key, and try to create a Derby DSN, to have seen this. I'd wager that many who like to help solve problems would not likely have Std (running Dev or Enterprise), so this (and the fact that many of them may not yet have worked with Derby) simply further winnows down the number of people able to help in this case.

You also counter how you wouldn't "just slipstream a "fix" in with no announcement and pretend like it never happened then make out like it's a user error." Are you referring to this bug? There's been no fix slipstreamed in. Not sure what you're referring to there.

But you also wonder "wouldn't it be listed somewhere as 'known issue'", and I'd say no, because in fact it doesn't seem to have been a known (or understood) issue. It is now, now that I've blogged it, and I've reported it (just yesterday, after writing the blog entry and responding here) in the Bug report page. So we can hope it will be solved.

I guess it just seems the rhetoric needs to be dialed down. I don't think things are quite what you've perceived them to be. It's a bug, yes, but not one that's been known and ignored quite the way you propose. I think some unique circumstances have been the cause of the challenge in resolving it. I hope you'll reconsider your stance on this issue.

Also, if you could mark the issue as answered (pointing to the earlier entry I offered) it would help any who find and wonder about the problem. Yes, it's an annoying one, but most do NOT know that it's caused by the Std license. Rather than leave them to wade through the heated discussion, it would help for them to quickly focus on the answer. Just trying to help everyone here, yourself included.

[ToBeNamedLater]

> It's not been known to anyone, that I can gather.

That's what surprises me considering how long this product has been out.

> there's no "cabal"

An unfortunate choice of words on my part. I apologize for that. I can only say in my defense that there are those of us who are just trying to make a living and don't have the time or resources to spend the amount of time it takes to keep abreast of betas and intricacies of the product internals. I need to be able to search somewhere (ideally KB, but web or groups is fine) and find the answer to a problem. That I couldn't find anything about this yet was later told "this has been discussed a lot" is something I can't reconcile. I'm a one-man shop who must pay all my own taxes and expenses, so every hour I spend searching the web or KB for this kind of thing is an hour that I'm not productive and not billing. It doesn't take long to rack up 3 hours a day of non-billable "overhead" searching. If I had the luxury of collecting a paycheck while doing these unproductive things, it would be less of an issue.

> rather than use it to make another "see, this is why CF sucks" kind of argument,

You misunderstand. I like CF. So much so that I've based my career on it. I'm trying to counter that "sucks" argument with my client who is being barraged by JSP and ASP types who want to throw the whole thing out and use incidents like this to bolster their argument. As I said, I'm a one-man shop who was lucky enough to get in here and do a good job. I'm fighting against medium and large consulting companies with vast resources at their disposal (who, in fact, promised to re-write my apps for free if they would toss me). I keep my position here because with CF it is easy to develop things quickly, I'm nimble, fast, thorough, and attentive. I could use a little backing.

> Are you referring to this bug? There's been no fix slipstreamed in. Not sure what you're referring to there

I'm referring to Adam's comment. One of his suggestions to address this problem was to download the (same) hotfix and re-install it because sometimes they put a newer one with a fix that wasn't in a previous one but don't change the version or give any indication that it's different (you have to check file dates and sizes).

> mark the issue as answered

Never noticed that before. I will do that.

[Newsgroup_User]

> You misunderstand. I like CF. So much so that I've based my career on it. I'm
> trying to counter that "sucks" argument with my client who is being barraged by
> JSP and ASP types who want to throw the whole thing out and use incidents like
> this to bolster their argument.

What I meant in my earlier post when you mentioned this is I think it's a
reasonably *good* sell of CF to be able to say "hey, I stumbled on this
really esoteric problem (and now that Charlie's identified it, you gotta
agree it's pretty esoteric!), and the guys on the community jumped on the
case as soon as I raised it, stuck with me, and we had it sorted within a
few hours; less than a day". I'm not trying to blow my own horn here - I
think in this case I wasn't actually much help - but Charlie sure helped
and I think that we kept the conversation going backwards and forwards -
regardless of tone - did encourage the investigation more. I reckon had
you posted something and been completely ignored, then that would suck.

I'm sure JSP & ASP have some idiosyncratic issues with them as well:
everything's got bugs.

I guess one needs to look at the glass and see if it's half-full or
half-empty.

--
Adam

[Newsgroup_User]

On Tue, 3 Mar 2009 17:31:42 +0000 (UTC), ToBeNamedLater wrote:

>> Are you referring to this bug? There's been no fix slipstreamed in. Not sure
> what you're referring to there
>
> I'm referring to Adam's comment.

This one:
>> I have known in the past for Adobe (although probably Macromedia @ the
>> time) to put up slightly bung installer downloads, which later get fixed.

> One of his suggestions to address this
> problem was to download the (same) hotfix and re-install it because sometimes
> they put a newer one with a fix that wasn't in a previous one but don't change
> the version or give any indication that it's different (you have to check file
> dates and sizes).

Just to put this in context, my experiences of this have been on the first
day something goes up for D/L (like an updater), the problem with the D/L
gets identified straight away and they replace the file. I'm not talking
about days or weeks or months later. I've had that perhaps twice (since
CF5). Other occasions I've known the D/L to get partially corrupted for
some reason: still OK enough to run the installer, but weird results ensue.
I've had this 3-4 times. I figured if machines you had installed CF on
were all doing something odd, then there's a chance your installer was bung
(for whatever reason), and a file-size check was a quick way check that.

Now I didn't explain all that, but I think you were pretty quick off the
mark to start passing judgement there.

--
Adam

[ToBeNamedLater]

Okay.

Whatever.