>Pete,
>
>First (I don't know if this has been fixed in 6.0), but in 5.0 - trying to join more than a couple tables freaked the thing out. I have views up to 7 or 8 joins with two or three updatable tables - view designer simply died.
>
I've never tried it with more than two tables but it's certainly ok with two

>Secondarily - and more generally - I will almost always go with a code created object (in the loose sense of the word) rather than a "visual" one for anything that is not visual in nature (like a form). All my database building, table building, view building, etc. etc .etc. is done in code. This is because:
>
>1) I have ULTIMATE CONTROL.
>2) It forces me to actually understand what is going on
>3) I can do it QUICKER - yes, I said QUICKER with my boilerplate code than I could "visually"
>4) I hate the code GENDBC put's out - I like my own "style" of coding, commenting, etc.
>
You can always hack the code gendbc produces.


>also - back to views specifically ..
>
>5) Just try doing a view like 'Select * from foo where &lcWhere" in the view designer, And I have tons of views like this.
>
I'll try that.


>Now - to the real question ...
>
>Does this make you a "bad" programmer! Aha! My point is made! No - of course not! You just have a different WAY of accomplishing the same thing. Would it make me "bad" if I were to tell you that I don't know where GENDBC even is? I'd have to look for it and 'figure it out" to run it. (been awhile). Now - if you took a test that was heavy on manually coding a view, wouldn't you feel a little side-swiped? I would if I were tested on specifics of GENDBC!
>
I know how to code it manually, but we have visual tools that I believe we should use.

>Wouldn't the best "Test" question be something more along the lines of "Create a working, updatable, parameterized view that joins the customer and invoice tables and do it in under three minutes"
>
>The RESULT is what counts, not the methodollagy.
>
I agree BUT, you should be able to choose your method.

Regards

Pete