embeded derby as client variable store

Forum|Forum|17 years ago
March 1, 2009
7 replies
3109 views

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.

This topic has been closed for replies.

ToBeNamedLaterAuthor

Inspiring

Okay.

Whatever.

Newsgroup_User

Inspiring

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

Newsgroup_User

Inspiring

> 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

ToBeNamedLaterAuthor

Inspiring

> 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.

ToBeNamedLaterAuthor

Inspiring

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

Community Expert

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.

/Charlie (troubleshooter, carehart. org)

Charlie Arehart

Community Expert

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.

/Charlie (troubleshooter, carehart. org)

ToBeNamedLaterAuthor

Inspiring

> 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

Inspiring

> 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

ToBeNamedLaterAuthor

Inspiring

> 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.

Sign up

To post, reply, or follow discussions, please sign in with your Adobe ID.

Sign in to Adobe Community

To post, reply, or follow discussions, please sign in with your Adobe ID.

Scanning file for viruses.

This file cannot be downloaded