On 4/19/06, David Elliott <[EMAIL PROTECTED]> wrote:
> Below is a part of my code
>
> And my question might be a simple onethe line that says IS NOT "">,equip_idle...does this mean I'll only have any entry if
> their is a value in it?
Yes, but a better way I think is to say but yeah,
>From: Roberto Perez [mailto:[EMAIL PROTECTED]
>>Sent: 04 March 2006 17:07
>>To: CF-Talk
>>Subject: RE: SQL Question
>>
>>
>>At 11:51 AM 3/4/2006, Jennifer Gavin-Wear wrote:
>>>can ignore this .. sorted it .. thanks
>>
>>
>>Good job :-
At 11:51 AM 3/4/2006, Jennifer Gavin-Wear wrote:
>can ignore this .. sorted it .. thanks
Good job :-)
Could you post the solution so that it gets archived and can be used
in the future by others who may have a similar problem?
Thanks,
Roberto
~~~
>can ignore this .. sorted it .. thanks
>
Well some of us would liketa know how ya sorted it Jen. :)
Will
~|
Message: http://www.houseoffusion.com/lists.cfm/link=i:4:234192
Archives: http://www.houseoffusion.com/cf_lists/thread
can ignore this .. sorted it .. thanks
>>-Original Message-
>>From: Jennifer Gavin-Wear [mailto:[EMAIL PROTECTED]
>>Sent: 04 March 2006 16:33
>>To: CF-Talk
>>Subject: OT: SQL Question
>>
>>
>>using a "between":
>>
>>where getdate() between tbl.fromdate and tbl.todate
>>
>>i'm getting a pro
Your misunderstanding - I would not really approve of comma separated lists
in columns -, I totally approve of bridge tables.
-Original Message-
From: Rick Faircloth [mailto:[EMAIL PROTECTED]
Sent: 07 December 2005 16:04
To: CF-Talk
Subject: RE: SQL Question. Compare one list to
Rick,
No sorry I meant I'd be ok with a list in a column if all I was doing was
displaying the list. for searching the look up table method makes more sense
to me. What I ended up implementing was
user table.
keyword table.
in the keyword table I have keywordID, userID, keyword.
On 12/7/05, Ric
orting through the list for matches as opposed
to using a look-up table or "bridge" table?
Rick
> -Original Message-
> From: John Wilker [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, December 07, 2005 10:18 AM
> To: CF-Talk
> Subject: Re: SQL Question. Compare one l
Robertson-Ravo, Neil (RX)
> [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, December 07, 2005 8:27 AM
> To: CF-Talk
> Subject: RE: SQL Question. Compare one list to another
>
>
> I agree with Russ here, I don't like it (for the third time) and
> I would not
> code or appr
Correct...
Bridge table, lookup table, map table, etc.
-Original Message-
From: Rick Faircloth [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 07, 2005 10:01 AM
To: CF-Talk
Subject: RE: SQL Question. Compare one list to another
So...what you're saying is that a "bridge
son-Ravo, Neil (RX)
> [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, December 07, 2005 10:01 AM
> To: CF-Talk
> Subject: RE: SQL Question. Compare one list to another
>
>
> PropertType table
> Property table
> Property + Type Lookup Table
>
>
>
>
>
&g
To: CF-Talk
> Subject: RE: SQL Question. Compare one list to another
>
>
> PropertType table
> Property table
> Property + Type Lookup Table
>
>
>
>
>
>
> -Original Message-
> From: Rick Faircloth [mailto:[EMAIL PROTECTED]
> Sent: 07 Decembe
I pretty much agree with the concensus here. For reading and displaying
only, a list in a single column seems ok to me. THis case I have now is a
new one for me, makes sense to put them in a seperate column.
~|
Logware (www.logwa
PropertType table
Property table
Property + Type Lookup Table
-Original Message-
From: Rick Faircloth [mailto:[EMAIL PROTECTED]
Sent: 07 December 2005 15:07
To: CF-Talk
Subject: RE: SQL Question. Compare one list to another
Ok...so...for my own edification...
If "bridge"
Sent: 07 December 2005 12:32
To: CF-Talk
Subject: RE: SQL Question. Compare one list to another
I have to disagree, it is a bad database design, but I agree there is times
when you might need to do it.
Denormalisation is often done when this provides performance increases.
In the below example, it
sults in HUGE queries and
massive tables, then you need to consider if you really need to do this.
Russ
-Original Message-
From: Robertson-Ravo, Neil (RX)
[mailto:[EMAIL PROTECTED]
Sent: 07 December 2005 12:11
To: CF-Talk
Subject: RE: SQL Question. Compare one list to another
I see wher
iginal Message-
From: Dave Watts [mailto:[EMAIL PROTECTED]
Sent: 07 December 2005 11:52
To: CF-Talk
Subject: RE: SQL Question. Compare one list to another
> It is not ideal; but it is not bad design pe se - there my be
> reasons to store them in this manner in some design cases.
No, act
> It is not ideal; but it is not bad design pe se - there my be
> reasons to store them in this manner in some design cases.
No, actually, that is a textbook example of bad database design. While you
may have reasons for doing this - I can't think of any offhand, but who
knows? - it would still b
It is not ideal; but it is not bad design pe se - there my be reasons to
store them in this manner in some design cases.
-Original Message-
From: Bryan Stevenson [mailto:[EMAIL PROTECTED]
Sent: 06 December 2005 16:35
To: CF-Talk
Subject: Re: SQL Question. Compare one list to another
Ended up implementing the more normalized approach. Less headaches in the
future are always prefered. THanks for the input.
~|
Logware (www.logware.us): a new and convenient web-based time tracking
application. Start tracking an
Makes sense. I'll see if I can move it that model now. better now than later
:)
On 12/6/05, Ian Skinner <[EMAIL PROTECTED]> wrote:
>
> Not sure I follow. Put each individual value in a column? ie
>
> column1 = keyword, column2 = keyword, columnN = keyword?
>
> Just set an upper bound on how many k
Not sure I follow. Put each individual value in a column? ie
column1 = keyword, column2 = keyword, columnN = keyword?
Just set an upper bound on how many keywords to allow. A keyword look up table
so to speak.
userID, colum1-N
NO That is worse then the list you are currently using.
Not sure I follow. Put each individual value in a column? ie
column1 = keyword, column2 = keyword, columnN = keyword?
Just set an upper bound on how many keywords to allow. A keyword look up
table so to speak.
userID, colum1-N
On 12/6/05, Bryan Stevenson <[EMAIL PROTECTED]> wrote:
>
> If you c
If you can John...tear the lists out and store each element as a seperate
record
(in a seperate table if needed). Storing lists of values in a field is a) bad
data design b) as you can tell a PITA to manipulate and maintain
Cheers
Bryan Stevenson B.Comm.
VP & Director of E-Commerce Developmen
tanks!
-Original Message-
From: Bobby Hartsfield [mailto:[EMAIL PROTECTED]
Sent: Monday, December 05, 2005 11:09 PM
To: CF-Talk
Subject: RE: SQL Question. Compare one list to another
Pretty good read in general too about UDFs in sql
...:.:.:.:.:.:.:.:.:.:.:.:.:.:.
Bobby Hartsfield
http
At
listLen
listPrepend
listSetAt
listToTable
N
-Original Message-
From: Bobby Hartsfield [mailto:[EMAIL PROTECTED]
Sent: 06 December 2005 05:09
To: CF-Talk
Subject: RE: SQL Question. Compare one list to another
Pretty good read in general too about UDFs in sql
..:.:.:.:.:.:.:.:.:.:.:.:.
istPrepend
listSetAt
listToTable
N
-Original Message-
From: Bobby Hartsfield [mailto:[EMAIL PROTECTED]
Sent: 06 December 2005 05:09
To: CF-Talk
Subject: RE: SQL Question. Compare one list to another
Pretty good read in general too about UDFs in sql
..:.:.:.:.:.:.:.:.:.:.:.:.:.:.
Bobby
Pretty good read in general too about UDFs in sql
..:.:.:.:.:.:.:.:.:.:.:.:.:.:.
Bobby Hartsfield
http://acoderslife.com
-Original Message-
From: John Wilker [mailto:[EMAIL PROTECTED]
Sent: Monday, December 05, 2005 11:55 PM
To: CF-Talk
Subject: Re: SQL Question. Compare one list to
> ..:.:.:.:.:.:.:.:.:.:.:.:.:.:.
> Bobby Hartsfield
> http://acoderslife.com
>
> -Original Message-
> From: John Wilker [mailto:[EMAIL PROTECTED]
> Sent: Monday, December 05, 2005 11:36 PM
> To: CF-Talk
> Subject: Re: SQL Question. Compare one list to another
>
&
r 05, 2005 11:36 PM
To: CF-Talk
Subject: Re: SQL Question. Compare one list to another
BTW, that link leads to a page with no entries.
On 12/5/05, Mark A Kruger <[EMAIL PROTECTED]> wrote:
>
> You can create a UDF (in SQL - not CF) that mimics the "listfind"
> function,
>
ficient or easily maintained.
>
> -Original Message-
> From: Ian Skinner [mailto:[EMAIL PROTECTED]
> Sent: Monday, December 05, 2005 5:24 PM
> To: CF-Talk
> Subject: RE: SQL Question. Compare one list to another
>
>
> I've got a table with a column that holds a c
storing lists in columns doesn't lend itself to optimal
> SQL
> code. I wouldn't expect this to be very efficient or easily maintained.
>
> -Original Message-----
> From: Ian Skinner [mailto:[EMAIL PROTECTED]
> Sent: Monday, December 05, 2005 5:24 PM
> To: CF-Ta
, storing lists in columns doesn't lend itself to optimal SQL
code. I wouldn't expect this to be very efficient or easily maintained.
-Original Message-
From: Ian Skinner [mailto:[EMAIL PROTECTED]
Sent: Monday, December 05, 2005 5:24 PM
To: CF-Talk
Subject: RE: SQL Question. Co
I've got a table with a column that holds a comma seperated list of keywords.
I'm just not seeing the solution right now.
I've got a keyword search where the user can put in a comma seperated list of
keywords. I need the query to search the DB to see if any of the keywords match
the keywords in
OK, so from what I can tell, the left join returns all Ads where there is no
corresponding uid in Members, yes?
(side note, try a foreign key with a cascading constraint to stop this from
happening again).
How about:
DELETE FROM Ads where uid NOT IN (SELECT uid
FROM Members)
Try it as a se
ya, I saw that -- sorry I was skimming too fast.
On Apr 9, 2005 12:06 PM, Johnny Le <[EMAIL PROTECTED]> wrote:
> I am using a LEFT JOIN, not an INNER JOIN. It would be equal if it is INNER
> JOIN.
>
> >oh ok, I saw a.uid=m.uid and thought that you were making them equal
> >in your query.
> >
>
I believe you want
SELECT a.id, a.uid
FROM Ads a
WHERE NOT EXISTS (
SELECT *
FROM Members m
WHERE m.uid = a.uid
)
That'll do a select of the rows you want to delete. Once you've
confirmed it correct, change the first line to "DELETE" and it'll
delete the rows.
cheers,
barneyb
On Apr 9, 2
I am using a LEFT JOIN, not an INNER JOIN. It would be equal if it is INNER
JOIN.
>oh ok, I saw a.uid=m.uid and thought that you were making them equal
>in your query.
>
>
>
>On Apr 9, 2005 11:04 AM, Johnny Le <[EMAIL PROTECTED]> wrote:
>>
~~~
oh ok, I saw a.uid=m.uid and thought that you were making them equal
in your query.
On Apr 9, 2005 11:04 AM, Johnny Le <[EMAIL PROTECTED]> wrote:
> Uid in Ads is not null. This is my attempt to get all the records that was
> deleted off Members but have not been deleted off Ads. Note that I
Uid in Ads is not null. This is my attempt to get all the records that was
deleted off Members but have not been deleted off Ads. Note that I have
Members.uid is null, not Ads.uid is null.
Johnny
>Why not just do this:
>
>DELETE
> FROM Ads
> WHERE uid IS NULL
>
>
>
>
>On Apr 9, 2005 10:
Why not just do this:
DELETE
FROM Ads
WHERE uid IS NULL
On Apr 9, 2005 10:26 AM, Johnny Le <[EMAIL PROTECTED]> wrote:
> Hi,
>
> My database is a mess. The programmer who did this didn't delete all the
> user related records once the users deleted their accounts. So I am trying
> to
> >>In all those years, you've never had a user come back
> >>and say, "You know
>>>that feature we said we'd never need - well we need it"
> Sometimes, but much less often than I have seen users
> never use a feature
> they were claiming not being able to live without.
Or never use that featu
> > How long does it take to create a linking table and a
> > handful of SQL statements,
>
> Too long if it is not necessary.
You could have done it several times over in the time you spent here
justifying not doing it.
> REUSE CODE! Use custom tags;
> See http://www.contentbox.com/claude/custo
>>In all those years, you've never had a user come back and say, "You know
>>that feature we said we'd never need - well we need it"
Sometimes, but much less often than I have seen users never use a feature
they were claiming not being able to live without.
--
_
> From: James Holmes [mailto:[EMAIL PROTECTED]
> I always design things properly the first time and I am
> always glad I did,
> because this always happens, despite what is in the specs doc
> (even though I
> tell them that if it is not in the specs doc they don't get
> it in the first
> versio
> From: Claude Schneegans [mailto:[EMAIL PROTECTED]
> Too long if it is not necessary.
I guess we will just have to agree to disagree, especially if you think 3
minutes is too much time up time to spend up front to gain scalability,
flexibility, etc.
~~~
6 February 2005 10:43
To: CF-Talk
Subject: Re: sql question
[snip]
>>I am not sure what experience you have
Just a master degree in Computer Science, about 30 years in programming,
about 15 years in database systems (I said 10, but it is really 15), and
about 9 in CF.
>> but in
It would definitly take bugger all time for me to create the tables and
model the query in TOAD.
-Original Message-
From: Michael T. Tangorre [mailto:[EMAIL PROTECTED]
Sent: Saturday, 26 February 2005 10:31
To: CF-Talk
Subject: RE: sql question
> From: Dave Watts [mailto:[EM
>>What if I want to know everyone in a given role?
If you have roles, then you have user groups, etc. It is a more complex
situation and THERE you're right,
(I'm right too) then a join table is the best.
I was talking of simple situations, just to say that "rules" should not
be taken too rigoro
>>ow long does it take to create a linking table and a handful of SQL
statements,
Too long if it is not necessary.
--
___
REUSE CODE! Use custom tags;
See http://www.contentbox.com/claude/customtags/tagstore.cfm
(Please send any spam to this address: [EMAIL
>>why would you delete all previous permissions???
Because it is simpler than looking which one where removed, delete those
ones,
then look for which one where added and insert the new ones. This takes
at least two loops.
>>If you are adding permissions a simple insert
>>if you are taking aw
> From: Dave Watts [mailto:[EMAIL PROTECTED]
> How long does it take to create a linking table and a handful of SQL
> statements, for crying out loud?
Thank you! I thought I was the only one who thought a table and a few
queries could be written in a few minutes
~~
turday, 26 February 2005 7:56
To: CF-Talk
Subject: Re: sql question
>>You bring everything back to CF, then
you loop through the list, change/delete stuff, then re-insert the list?
If you insist on doing it the most clumsy way, of course it looks worse ;-)
When updating, just loop on the
> Good for you, mine don't like I charge them for useless code.
How long does it take to create a linking table and a handful of SQL
statements, for crying out loud?
> REUSE CODE! Use custom tags;
> See http://www.contentbox.com/claude/customtags/tagstore.cfm
> (Please send any spam to this addre
4- when updating, you have to delete first all previous permissions for
that user from the table, then insert all new records.
Apperently you aren;t getting something...why would you delete all
previous permissions??? If you are adding permissions a simple insert
if you are taking away you just de
>>your database should be normalized in
>>this case...it allows for more scalability.
This is true in theory. This is what I learned about 10 years ago when I got
involved in database programming.
Now I that have more experience, I've learned to apply theory with judgement ;-)
--
>>You bring everything back to CF, then
you loop through the list, change/delete stuff, then re-insert the list?
If you insist on doing it the most clumsy way, of course it looks worse ;-)
When updating, just loop on the list to generate check boxes in a form, then
just
use one update statement
>>I don't know about your clients, but the people I work for and do
work expect more than than the
>>bare minimum.
Good for you, mine don't like I charge them for useless code.
--
___
REUSE CODE! Use custom tags;
See http://www.contentbox.com/claude/customt
>>using a list requires fetching data, parsing it, and then fetching
more data.
Depends how you do it:
1- when a user logs in, get his permission list from into a session
variable from the same query as other user parameters.
2- in any template a user permission needs to be checked, just do
riginal Message -
From: "Claude Schneegans" <[EMAIL PROTECTED]>
To: "CF-Talk"
Sent: Friday, February 25, 2005 1:08 PM
Subject: Re: sql question
> Then, if it is to the extend that a join table becomes more efficient, it
> will be time to modify it and the customer
> >>any time you want to find an
>
> >>idividual value in this comma seperated list your design begins to
> >>enter the bad design area.
>
> Any time some one uses "any time" regarding rules about database,
> the rule looks suspect to me ;-/
>
I agree but notice I said begins...I did not say it
I would completely disagree...your database should be normalized in
this case...it allows for more scalability. If you like your comma
seperated fields create a view but your true data store should not
have just comma deliminated crap, ecspecially if you are trying to
look for a single value in the
> > From: Claude Schneegans [mailto:[EMAIL PROTECTED]
> > Then, if it is to the extend that a join table becomes more
> > efficient, it will be time to modify it and the customer who
> > has new specs will pay for the necessary development.
> > At the time a project is developped, it is not fair to
> From: Claude Schneegans [mailto:[EMAIL PROTECTED]
> Then, if it is to the extend that a join table becomes more
> efficient, it will be time to modify it and the customer who
> has new specs will pay for the necessary development.
> At the time a project is developped, it is not fair to have
>>clients/customers/users often make changes all the time requiring us to
>>expand what we initially started with.
Then, if it is to the extend that a join table becomes more efficient, it will
be time to modify it and the customer who has new specs will pay for the
necessary development.
At t
> From: Claude Schneegans [mailto:[EMAIL PROTECTED]
> In the wider and most general case, you are right, but this
> is only theory and it is completely the oposite in most simple cases.
> Take for instance an intranet where users can
> - Edit content (ED)
> - Edit images (EI)
> - Edit News (EN)
>
>>This IS bad database modeling,
In the wider and most general case, you are right, but this is only
theory and it is completely the oposite in most simple cases.
Take for instance an intranet where users can
- Edit content (ED)
- Edit images (EI)
- Edit News (EN)
- Edit agenda (EA)
- Manage use
>>any time you want to find an
>>idividual value in this comma seperated list your design begins to
>>enter the bad design area.
Any time some one uses "any time" regarding rules about database,
the rule looks suspect to me ;-/
>> And it does break normailization rules...
If so, then normaliz
>>Yes, strong comma separated lists in a DB is not ideal - though it is not
>>bad design as in some cases it does make sense - and it does not break any
>>'rules'.
Exact, all depends on the number of possible elements in the list and the
overall size of the field.
If for instance the maximum nu
I compeelty agree a denormailzed database schema is not a bad design
in some cases, ecspecially when performance is considered UPC desc in
asumarray table for example, but Niel said puting a comma seperated
list does not break any 'rules' I was simpley making a point it does
break a rule, not jsut
I didn't design it, but as a contractor I have to work with it. A redesign is
not an option at this point.
thanks for the multitude of responses. =)
~|
Discover CFTicket - The leading ColdFusion Help Desk and Trouble
Ticket app
> From: Adam Haskell [mailto:[EMAIL PROTECTED]
> This is going to get off topic butany time you want to find
> an idividual value in this comma seperated list your design
> begins to enter the bad design area. And it does break
> normailization rules...
I knew this topic was gonna last about 1
)
[mailto:[EMAIL PROTECTED]
Sent: vrijdag 25 februari 2005 15:39
To: CF-Talk
Subject: RE: sql question
LOL, I have to disagreewhile I don't think it is good design per say
there may be a valid database theory behind it It does not break any
rules at all if there is good reason to
05 14:27
To: CF-Talk
Subject: Re: sql question
This is going to get off topic butany time you want to find an
idividual value in this comma seperated list your design begins to
enter the bad design area. And it does break normailization rules...
Adam H
On Fri, 25 Feb 2005 14:00:10 -, Robe
ry 2005 14:01
> To: CF-Talk
> Subject: Re: sql question
>
> First off i want to point out that anytime you do something like it
> should occur to you that this is probably not the best DB design and
> could lead to more issues down the road...if this is indeed on of the
> rare cas
in MS SQL where 11 in items is not valid syntax. The other will not
work either. Since it only is evaluating the entire column out, it
does not parse it to realize oh it has commas lets treat it as
seperate members. 11 IN (col1,col2,col3) is valid for finding a
record where col1 2 or 3 have a val
Yes, strong comma separated lists in a DB is not ideal - though it is not
bad design as in some cases it does make sense - and it does not break any
'rules'.
-Original Message-
From: Adam Haskell [mailto:[EMAIL PROTECTED]
Sent: 25 February 2005 14:01
To: CF-Talk
Subjec
If that doesn't work, or works slowly, it may be a good idea to
revisit the design itself, and use a table to relate items instead of
a list inside of a column.
-Joe
On Fri, 25 Feb 2005 08:55:46 -0500, Matthew Small <[EMAIL PROTECTED]> wrote:
> This *might* work:
>
> select * from myTable
> whe
First off i want to point out that anytime you do something like it
should occur to you that this is probably not the best DB design and
could lead to more issues down the road...if this is indeed on of the
rare cases where this design makes sense. Then one option is to do
this CHARINDEX(','+item+'
This *might* work:
select * from myTable
where 11 in items;
or
select * from myTable
where 11 in (items);
- Matt Small
-Original Message-
From: Protoculture [mailto:[EMAIL PROTECTED]
Sent: Friday, February 25, 2005 7:41 AM
To: CF-Talk
Subject: sql question
I have a list of items i
Andy,
Try:
YEAR(dateadd(year,-1,tabInvoices.InvoiceDate)
-mk
-Original Message-
From: Andy Ousterhout [mailto:[EMAIL PROTECTED]
Sent: Tuesday, November 30, 2004 11:37 AM
To: CF-Talk
Subject: SQL Question
In MS SQL, why does this work:
CASE YEAR(tabInvoices.InvoiceDate)
but this thr
>Use CFQUERYPARAM with the 'list' attribute and it should work:
>
>...
>dealer_zip IN (value="#returnedzips#" list="true" />)
>
>Just make sure that the zips in 'returnedzips' don't have truncated
>leading zeros.
>
>cheers,
>barneyb
That worked!
>
>On Fri, 05 Nov 2004 19:51:24 -0400, Jeff Fongem
Use CFQUERYPARAM with the 'list' attribute and it should work:
...
dealer_zip IN ()
Just make sure that the zips in 'returnedzips' don't have truncated
leading zeros.
cheers,
barneyb
On Fri, 05 Nov 2004 19:51:24 -0400, Jeff Fongemie
<[EMAIL PROTECTED]> wrote:
> Hey everyone,
>
> I have a table
>This is a scary thing to hear a web developer say. If you really feel that
>uncomfortable about joins, you should immediately stop what you're doing
>and study relational databases until you understand the basics - joins,
>normalization, and declarative referential integrity. It really is that
>im
> This is why I stay away from joins - they're so complicated
> that when I cant get them to work, that's all I concentrate on. ;-)
> ...
> Blaine Korte
> Web Developer
This is a scary thing to hear a web developer say. If you really feel that
uncomfortable about joins, you should immediately st
> Wow, do I ever feel stupid. It was the output stage that I had my problem
> with. It's fixed, that join query runs fine.
I'm glad it worked out. No need to feel stupid: getting a second (third,
fourth,...,nth) pair of eyes to look at the issue freshly is one of the
great things about this
aine Korte
To: CF-Talk
Sent: Tuesday, October 12, 2004 12:20 PM
Subject: RE: SQL Question...
Wow, do I ever feel stupid. It was the output stage that I had my problem
with. It's fixed, that join query runs fine.
This is why I stay away from joins - they're so complicated th
Wow, do I ever feel stupid. It was the output stage that I had my problem
with. It's fixed, that join query runs fine.
This is why I stay away from joins - they're so complicated that when I cant
get them to work, that's all I concentrate on. ;-)
Thanks a bunch for the help, Matthieu!
Blaine
> Can anybody lend a hand and help me out on this one? All it does is
return
> 1 row no matter how many rows are in the sizeLine table..
Blaine,
I'm not exactly sure why this is happening, but here are some ideas of what
to check:
1) Forgive me for suggesting the obvious, but since it's
Thanks. I was being myoptic and only thinking about this in SQL. Easy
solution.
Thanks
-Original Message-
From: Douglas Knudsen [mailto:[EMAIL PROTECTED]
Sent: Friday, October 01, 2004 11:03 AM
To: CF-Talk
Subject: Re: SQL Question: Using query to generate report columns
If
If you have
Customer1 Item #1
Customer1 Item #2
Customer1
Customer2 Item #1
Customer2 Item #2
Customer2
then you can use the GROUP attribute of cfoutput, make sure you have
oreder by customer in your SQL and
#foo.customer#
#item#
some
Turn it into a Stored Procedure and just call the stored procedure.
Either using cfquery or cfstoredproc.
_
From: Tony Weeg [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 22, 2004 10:34 AM
To: CF-Talk
Subject: Re: sql question
it cant be ommitted when creating a view and
you do
I wonder if SQLBATCHER on CFLIB may help - just looked at this this morning!
http://www.cflib.org/udf.cfm?id=1127
On Wed, 22 Sep 2004 10:33:55 -0400, Tony Weeg <[EMAIL PROTECTED]> wrote:
> it cant be ommitted when creating a view and
> you do that from a single dsn in cfmx and you
> have to r
Well, really it should be an SP.
_
From: Tony Weeg [mailto:[EMAIL PROTECTED]
Sent: 22 September 2004 15:34
To: CF-Talk
Subject: Re: sql question
it cant be ommitted when creating a view and
you do that from a single dsn in cfmx and you
have to reference the database.
CREATE VIEW
it cant be ommitted when creating a view and
you do that from a single dsn in cfmx and you
have to reference the database.
CREATE VIEW must be first in the sql statement, unless its preceded by a "GO"
heres what im doing...
we are using a distributed partitioned view, and when
we make table c
I don't think so no, but GO is not required in SQL, it can be ommited.
_
From: Tony Weeg [mailto:[EMAIL PROTECTED]
Sent: 22 September 2004 14:59
To: CF-Talk
Subject: ot: sql question
is it true that we cannot use go in sql statements using cfquery?
--
tony
Tony Weeg
macromedia cert
correct (if you mean for sql server)
> is it true that we cannot use go in sql statements using cfquery?
[Todays Threads]
[This Message]
[Subscription]
[Fast Unsubscribe]
[User Settings]
[Donations and Support]
I think I solved it Join the document table in twice and in the join
clause added the condition
SELECT
R.TEAMING_AGREEMENT_ID,
R.ROUTE_GROUP_ID,
B.BUSINESS_NAME,
T.OPPORTUNITY_ID,
D.DOCUMENT_NAME AS TEAMING_AGREEMENT_DOCUMENT,
D.DOCUMENT_EXTENSION AS TEAMING_AGREEMENT_DOCUMENT_EXTEN
Monday, August 16, 2004 3:32 PM
Subject: Re: SQL Question
I think you'd probably have to have a temp table and save a record to it
and then delete out the entire original table and then insert the
single row back into the table from temp.
On Mon, 16 Aug 2004 15:19:39 -0400, Qa
Is it 7 or 2000 you're using? On 2000 I've used this before...
SELECT TOP 1 *
FROM table
ORDER BY NEWID()
Double check that is is bringing back a random row as it was a while ago
that I used it. In fact I think it was on 7 and I may have used something
else.
DELETE FROM yourTable
WHERE some
101 - 200 of 528 matches
Mail list logo
