The original gig was rewriting a couple of templates for them every
week or so. I pointed out the issues with Access and made some
recommendations and now this is going to be a major part of what is
very likely going to be -- slowly but surely -- a rewrite of their
entire system.
Maybe HXTT
: Should we support Access?
Matt,
How exactly have you configured these date/time fields? The fields I
refer to were created via a cfquery statement, as in
cfquery
username=#myDBUserName#
password=#myDBPassword#
datasource=#DSN#
CREATE TABLE myfile (
ID COUNTER
Drop it imho.
PostgreSQL, MySQL and SQL Server should be more than enough for a forum
app.
-Original Message-
From: Stan Winchester [mailto:[EMAIL PROTECTED]
Sent: 07 June 2005 17:13
To: CF-Talk
Subject: Should we support Access?
As many of you know from my previous posts we have had
Stan,
My knee-jerk reaction is to say 'No'. By supporting Access, you could be
propogating the myth that Access is a sufficient databse to use for web
applications. In my opinion, Access would never be the DB of choice, other
than to track my DVD collection...but I would never look at it
Personally, I wouldn't bother with Access support, the issue of
cfqueryparam being one of the reasons.
That being said, I can do a lot more than imagine production systems
running off of Access. I can point to a couple. Production Intranet,
Online Training/Presentations, Forums, and probably a
At the absolute opposite end of the scale, have you considered Oracle
support?
~|
Logware (www.logware.us): a new and convenient web-based time tracking
application. Start tracking and documenting hours spent on a project or
A SQL Server, MySQL, ect. field data type varchar(500)
with cfqueryparam set
as follows: cfqueryparam value=#Comments#
cfsqltype=CF_SQL_VARCHAR
maxlength=500 works fine in SQL Server, MySQL, ect.,
but breaks in
Access. If I remove the maxlength=500 it works.
Personally I don't use
My $.02 I am a SQL Server Oracle user/developer. I have dabbled
with MySQL and have found it to be adequate for those sites I have
used to build with it, albeit without SP support (which MySQL 5.0
adds).
Given that there is a free RDBMS available (MySQL), I would drop any
idea of supporting
-Original Message-
From: Stan Winchester [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 07, 2005 12:13 PM
To: CF-Talk
Subject: Should we support Access?
As many of you know from my previous posts we have had a forums
application
in beta testing for a while. It was developed
I support SQL Server, mySQL, Access and Oracle for my ContentMonger
Pro cms and have done so for some time so I feel your pain.
Short answer: Do it. Its amazing how many people use Access for a
variety of reasons.
The same goes for Oracle, although you will indeed introduce more
issues into
:12 PM
To: CF-Talk
Subject: Re: Should we support Access?
I support SQL Server, mySQL, Access and Oracle for my ContentMonger
Pro cms and have done so for some time so I feel your pain.
Short answer: Do it. Its amazing how many people use Access for a
variety of reasons.
The same goes for Oracle
2:12 PM
To: CF-Talk
Subject: Re: Should we support Access?
Access will explode on contact with ANY date field when you try to use
cfqueryparam on it. None of the cfsqltypes work so you have to write
your code with this in mind and protect yourself in other ways
The same goes for Oracle, although you will indeed
introduce more issues into your code (most of which
revolve around inserting conditional code that
inserts the nextval of a sequence when creating
a new record... no big deal.
I don't use sequences myself... I'd love to... but until they're
Matt,
How exactly have you configured these date/time fields? The fields I
refer to were created via a cfquery statement, as in
cfquery
username=#myDBUserName#
password=#myDBPassword#
datasource=#DSN#
CREATE TABLE myfile (
ID COUNTER not NULL PRIMARY KEY,
PostDate
On 6/7/05, Kevin Aebig [EMAIL PROTECTED] wrote:
The real question is whether or not these are the types of clients you want
to deal with. The type that would want to use Access instead of MySQL are
generally hands-on clients. They believe they know more than they actually
do and regularly play
15 matches
Mail list logo
