I agree that it is better to write SQL directly, rather than using a QBE(Query
By Example) grid, while you are learning SQL. However, once you know SQL
well, you can use higher level tools since you will understand how they work
(in terms of their SQL code generation). This follows the principle that
it is often better to do things the hard way first, followed by the easy
way, so you gain a good understanding of the "Nuts and Bolts".

Personally, I have moved away from building SQL strings in code using simple
string concatenation, to a greater reliance on VB class modules whose properties
represent components of an SQL statement. Using OO principles in building
SQL strings provide a number of advantages. You can automatically handle
topics like how to handle special characters (like the single quote) within
a where clause, as well as which wildcard to use to satisfy the RDBMS you
are dealing with(To handle variations in the SQL dialects). This assists
me in writing solid readable code under a deadline.


>
>I am new to SQL myself. Reading a textbook on the subject which states it
>is better to write the SQL than use a graphic designer.
>
>I am learning a lot more about SQL by writing the code and my diagrams look
>great when I publish them in the SQL Server Enterprise Management evironment.
>
>"Al" ADDenton wrote:
>>
>>"Al" <ADDenton@visto.com> wrote:
>>>
>>>Hey, I'm having alot of trouble trying to apply referential integrity

on
>>some
>>>tables in SQL Server through a data diagram. I know there has to be a

way
>>>to 'visually' do it but I don't have a clue. I assumed that I could just
>>>'highlight' the field and 'drag' to the 2nd table abd viola---nope.
>>>
>>>Any clues anyone ?
>>>
>>>

>>
>>I just got it.... Never mind. I was trying to drag on a bad location.
>>

>