I don't mean to beat a dead horse here... and I think this is actually
getting somewhere, so I'll keep commenting.
> >Versus database's on NT? I'm confused here.
> >
> VS CFINSERT and CFUPDATE which, not too surprisingly, most people who
> start in CF use all the time.
Ahhh... this is an oversight on my part. I, nor do any of my co-workers,
ever use them. Given that we know SQL rather well it seems unnatural to
take a shortcut on such a simple task. Plus, like you mentioned, it
destroys portability. The issue with them not working isn't something
that should be pushed onto the DB, IMHO. If the application provides a
tag, which doesn't work across databases which it's supposed to support
then it's the application's fault (CF in this case).
> >permissions have to be set properly (including the
> >database password when you create your data source in Administrator),
> >
> >
> >Versus NT ... where you don't have to secure the system? <boggle>
> >
> Right. And where you don't have to set permissions for every file in
> every directory. I'm not saying NT's way of doing it is better, it
> obviously isn't. What I'm saying is that if you've not run into this
> before, exactly nothing works until you give specific permissions to the
> datasource and to each level you plan call with local anchors or FTP into.
Every file, and every directory, on NTFS has permissions. Or am I wrong
here? A default install, using your distro specific packages, should give
you exactly what you're looking for. No chmod, no chown, no adduser
commands neccessary. Yes, perhaps you should set a password on the
account which accesses the DB. Passwords on the DB though? Not that I
know of in PG. I'll give you that mySQL is a pain in the ass when it comes
to this, though. Their "froofy-loofy" authentication scheme baffles me
time and time again.
This is probably one of those "agree to disagree" points. If a co-worker
botches up my PG database, I can recover it w/out much sweat. If one of
them botches up SQL server and I'm stuck fixing it you'll usually find me
craving a few beers by noon that day. It seems you're more comfortable
the other way around.
> >>and the placement of timestamp fields is critical in SELECT statements
> >>to avoid locking up the Server CPU.
> >>
> >
> >I've never seen this occur except in your installation. I can select a
> >timestamp with that field being that last one in the query w/out problems.
> >
> I have scores of error messages on this point, where the only difference
> was the location of the field in the query. If new users have a weird
> error that makes no sense and which is not covered in any reference
> guide, I suggest they try stacking the timestamps first and the
> numerical fields second. When I did, my errors went away.
>From CF pages though, right? I diddled around with queries that did just
that in 'psql' and they all return fine. This means the error is
somewhere within CF. Be it the application server, or the driver. Either
way, you can't blame PG for short comings on Allaire/Macromedia's side.
> >
> No it doesn't . This is a typical expert response to this issue. I
> realize you can set up test
> instances where PostgreSQL will acccept an empty value, but it has to be at the end
>of the query and the value in front of it has to not have a trailing comma. You can
>also fake it with the actual word NULL or with a couple of '' quotes. But if you take
>a query generated by phpPgAdmin (which puts quotes in automatically in NULL numerical
>fields) and take the quotes out, and then run it, it won't work. Plain and simple. It
>chokes on the comma which it interprets as a value. Sure you can take the comma out
>if you only have one. But if you have 98 fields, as I did the other day, you can't
>just drop the delimiters.
Again, an agree to disagree point. I've got two other developers working
with me on a project who've never used PG before. Not one of them has
ever asked me why PG handled anything in an odd fashion. If you throw
proper, robust SQL at it it works just fine. I'd -rather- it broke on
less than perfect SQL... maintaining garbage written by a sloppy coder
down the road would is a horrid experience.
> >>Beyond that, databases on Linux can't simply be copied
> >>over as they can on NT, so the methodology of working with data is
> >>different.
> >>
> >
> >createdb db2
> >pg_dump db1 | psql db2
> >
> That's a script, not a copy. If the script fails, you're up the creek
> without a paddle. And it will fail if you haven't been very careful with
> the permissions... [snip]
Again, agree to disagree. I've used these features to make backups of
DBs, snapshots at certain times, test cases, etc, etc. It's a pretty
shoddy way of doing it perhaps, but it's easy and it works. You can
migrate a schema from SQL 7.0 to PG fairly simple thanks to it's ability
to import plain text nicely. Sure, you hae to tweak SQL7's output a bit,
but it doesn't take too long.
On the other hand... try migrating from Sql 6.5 to Sql 7.0 sometime. Hair
pulling experience. Point, click, then begin cursing. :). It's all a
matter of past experiences I suppose.
<begin kicking dead horse>
Sorry, but I just want to refute these so any newbies running through the
archives know the "ugly" alternatives to your tools.
> I'll tell you why new users need this, they need it because they are
> going to have to use the KDE superuser file manager to dig down to the
> CSV file, open it up in Keditor and try to fix the errors caused by
Nothing wrong with using pico, emacs, vi, vim, nvi, joe, or whatever
editor you feel comfortable with. If you're really tied to using a point
and click editor I recommend either FTPing the file back and forth, or
using Samba so you can pop it up in your native Win32 based editor.
> COPY, to stop and restart the CF process
/etc/rc.d/coldfusion stop && /etc/rc.d/coldfusion start
How do you even do that in a GUI? I've never tried. Its good to know how
to do things like this at console, because you can get to one of those
alot quicker usually. I've literally been there early in the morning
standing in my living room with nothing but a towel on, SSHing into a
serve to restart a hung CF process.
> and to use System Guard to
> check to see if one of their misplaced timestamps has caused their
> server's CPU to lock up. If you don't check your CPU load after running
> new queries, you're just asking for trouble.
'top' or 'uptime' works fine for me.
</stop kicking dead horse>
> This is the kind of thing I notice the experts don't actually have much
> to say about, the practical issues of using CF Linux and Postgresql.
> When you actually get your table's converted and start hitting them with
> queries that worked just fine on the NT side, suddenly there are BIG
> problems. I haven't mentioned all of them by any means, for example the
> way CF Linux radio buttons generate the variable "on" which is not
> understood by Postgresql which actually wants "true". Most of the
> issues I've just mentioned are not dealt with by anyone. Suggesting they
> don't exist isn't really very helpful.
Again, these are CF issues, not PG or Linux issues.
Case closed I suppose. It's not the DB's fault, or the OSes fault, CF on
Linux just performs shoddily, inconsistently, and flys like a paper cup.
When this thread popped up I bit my tongue, wanting to keep from saying
anything anti-CF because of my own bad experiences w/ it on Linux. The
more and moer I read Frank's posts (which I disagree with slightly) ... I
realized that maybe CF on Linux (at least 4.5.x) is a really bad idea for
a newbie. The very matter that it doesn't act -consistent- here is a huge
pitfal for somebody just stepping into the arena. How are they supposed
to know whether it's PG, Linux, or CF's fault when something goes wrong?
They don't... and I can't blame them when they put the blame on the wrong
portions of the system either.
Hopefully CF 5.0 will act appropriately. We've been told that there's
been significant stability/performance improvements on the Linux side and
I genuinley hope there have been.
<shrug>
Justin Buist
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Structure your ColdFusion code with Fusebox. Get the official book at
http://www.fusionauthority.com/bkinfo.cfm
------------------------------------------------------------------------------
Archives: http://www.mail-archive.com/cf-linux%40houseoffusion.com/
To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/cf_linux or send a
message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
