DinoRS, if I am reading that query correctly, isn't it saying "show only results where you have less than 1 result set available" not "more"?
The WHERE clause is saying "WHERE 1 < (a set of data)". The subquery is likely going to return more than 1 value UNLESS you only have 1 salesman_id value.
Michael.Leach2015 - think of that last part of the where as a subquery returning a single INT column which is a count of customers grouped by the salesman_id but only where the salesman_id exists in the salesman table. The subquery will return 1 integer per salesman_id that exists in both tables.
That query though I think will always return nothing won't it? I am trying to think of a case where a COUNT(*) on customer will return 0 when comparing a salesman_id to the salesman table.
As for your second question about using the GUI to re-generate a table, I am not aware of any built-in way to do this, but I wouldn't want to do it with any large tables anyways. If the script gets too long, you will start seeing Out Of Memory exceptions thrown in SSMS. These are SSMS errors though, not SQL Server errors so you don't need to worry about the SQL instance crashing or anything like that.
But if you are looking for a quick and easy way to create a duplicate of a table, the EASIEST (although not recommended) way would be something like:
The reason I don't like this method is the datatypes are being determined entirely by the SQL engine this way. My preferred method is to use CREATE TABLE to build up the new table, then select into the new table. Plus, SELECT * is good to avoid where possible.
That being said, I will use the above type of query if I am needing to fix some bad data in the database and want to have a backup of the original table prior to me making my changes JUST in case I break something, but even then I prefer to create the new table and INSERT INTO it. On a test/dev system I may use some bad habits (like SELECT * INTO), but I wouldn't run something like that on live.
I also don't use the GUI for much apart from intellisense. I tend to avoid using a lot of the GUI features as I find them to be troublesome at times. The scripting table as (or procedure or trigger or whatever) usually works fine, but I find at times the right-click menus in SSMS take forever to populate and in the time it takes for the menu to pop up, I could have just done a TSQL query to get the same result. I have one system that if I right click on a trigger, it takes 3-5 minutes before the menu pops up and all I can do is sit and wait for it to pop up as it freezes SSMS. I have another system where if I connect to it in the Object Explorer, it will show the name and take 2 minutes before it allows me to expand and after expanding, takes another 2 minutes before the agent option will show up and expanding that? you guessed it... another 2 minutes. Mind you, if I match the SSMS version to the SQL Instance version, this latency goes away, but then I end up having 6 copies of SSMS running depending on what I am connecting to which also becomes a pain in the behind.