Error in Query

The database scheme consists of four relations:

Product(maker, model, type)
PC(code, model, speed, ram, hd, cd, price)
Laptop(code, model, speed, ram, hd, screen, price)
Printer(code, model, color, type, price)

The relation "Product" shows the maker, model number, and type (pc,
laptop, or printer). It is assumed that model numbers are unique for
all the makers and product types. For each model number specifying pc
in the relation "PC", its listed speed (of the processor in MGz), total
RAM (in MGb), hd capacity (in Gb), CD ROM speed (for example, '4x'),
and the price. The relation "Laptop" is similar to that one of PCs
except for the CD ROM speed which is replaced by screen size (in
inches). For each printer model in the relation "Printer" it is pointed
whether the printer is color or not (color attribute is 'y' for color
printers; otherwise it is 'n'), printer type (laser, jet, or matrix),
and the price.

I need to write a query for Find printer makers.
Result set: maker.

My Query is

select distinct product.maker from product inner join printer on
product.model = printer.model

I get the message
Your query produced correct result set on main database, but it failed
test on second, checking database.
* Wrong number of records (less by 1)

This question is an SQL exercise in URL http://www.sql-ex.ru/

Can anyobe explain me "correct result set on main database," why "but
it failed test on second, checking database."
* Wrong number of records (less by 1)

Thank you very much,

MiksHi Miks

> Can anyobe explain me "correct result set on main database," why "but
> it failed test on second, checking database."
> * Wrong number of records (less by 1)

My guess (emphasis on "guess") is that it has something to do with the fact
that you don't need a second table for this query. The writers of this
website, must be doing some sort of parsing of your query, this is not a
standard SQL Server error message.

This query is sufficient

select distinct maker from Product where type = 'printer'

--
-Dick Christoph
"Miks" <akmeera2k4@.gmail.com> wrote in message
news:1142418307.696828.171550@.j33g2000cwa.googlegr oups.com...
> The database scheme consists of four relations:
> Product(maker, model, type)
> PC(code, model, speed, ram, hd, cd, price)
> Laptop(code, model, speed, ram, hd, screen, price)
> Printer(code, model, color, type, price)
> The relation "Product" shows the maker, model number, and type (pc,
> laptop, or printer). It is assumed that model numbers are unique for
> all the makers and product types. For each model number specifying pc
> in the relation "PC", its listed speed (of the processor in MGz), total
> RAM (in MGb), hd capacity (in Gb), CD ROM speed (for example, '4x'),
> and the price. The relation "Laptop" is similar to that one of PCs
> except for the CD ROM speed which is replaced by screen size (in
> inches). For each printer model in the relation "Printer" it is pointed
> whether the printer is color or not (color attribute is 'y' for color
> printers; otherwise it is 'n'), printer type (laser, jet, or matrix),
> and the price.
> I need to write a query for Find printer makers.
> Result set: maker.
> My Query is
> select distinct product.maker from product inner join printer on
> product.model = printer.model
>
> I get the message
> Your query produced correct result set on main database, but it failed
> test on second, checking database.
> * Wrong number of records (less by 1)
> This question is an SQL exercise in URL http://www.sql-ex.ru/
> Can anyobe explain me "correct result set on main database," why "but
> it failed test on second, checking database."
> * Wrong number of records (less by 1)
> Thank you very much,
> Miks|||homework?|||any place where you can find the answer of these exercies?

im stuck at exercse 10:

Exercise: 10
Find the printers having the highest price.
Result set: model, price.

my query:

select model, max(price)price from printer

http://www.sql-ex.ru/exercises.php#answer_ref

any place for the answers?|||Hi Daniel

Here is one answer (One SQL Query that works)

select Model, Price
from Printer
where price = (select max(price) from Printer)

--
-Dick Christoph
"Daniel" <dtukkers@.gmail.com> wrote in message
news:1143709387.198548.201780@.z34g2000cwc.googlegr oups.com...
> any place where you can find the answer of these exercies?
> im stuck at exercse 10:
> Exercise: 10
> Find the printers having the highest price.
> Result set: model, price.
> my query:
> select model, max(price)price from printer
> http://www.sql-ex.ru/exercises.php#answer_ref
> any place for the answers?

error handling and transactions - speed question

I've been very carefully studying
http://www.sommarskog.se/error-handling-II.html recently. I went through it
some time ago before I was very familiar with working in SQL and it was all
sort of mysterious to me. Now I'm finding it to be very helpful.
Here's my issue right now: I have a former coworker who has been wroking in
sql 2k for several years now (we tend to disagree often on programming
techniques). When I asked him today how extensively he implements the sorts
of strategies detailed in Erland's articles he said that he rarely does any
of this. I was surprised. He said that occasionally and with great restraint
he'll use a begin/commit structure. He says that if you have a system with
many users then you have to worry about the system getting bogged down in
transactions. I mentioned the classic example of transferring money from a
savings account to a checking acount and what if something fails between the
2 update statements and he said that if you have a banking system where
thousands of people are hammering away at the system all day long then using
transactiosn in such a situation would be detrimental to performance. He
thinks that in theory using begin/commmit and @.@.error is very good but in
it's not very practical in the real world. I'm thinking that would be true
if you didn't design your error handling carefully as Erland outlines. I
would very much appreciate some feedback from the experts on this topic
because in my opinion, not handling errors at all is a bad idea. Is my
friend way off, somewhere in the middle or right on target?
Thanks,
KeithLet me guess, he's the type of guy who takes a chance when bicycling into a
crossing, and don't
break in order to not loose speed; hoping that no car will intersect?
Sure, if your customer (MD, president, or whatever) agrees that some crap in
the database is OK, you
don't have to worry (as much) about transaction handling. But make sure it i
s a conscious decision,
taken higher up in the organization and make sure you have this in writing (
or it will be your ass).
Another way of looking at a DBMS is as a state machine. Each modification ta
kes you from one state
to another state. With transactions, you can protect yourself from disallowe
d states.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Keith G Hicks" <krh@.comcast.net> wrote in message news:ugsl8asTGHA.1576@.tk2msftngp13.phx.g
bl...
> I've been very carefully studying
> http://www.sommarskog.se/error-handling-II.html recently. I went through i
t
> some time ago before I was very familiar with working in SQL and it was al
l
> sort of mysterious to me. Now I'm finding it to be very helpful.
> Here's my issue right now: I have a former coworker who has been wroking i
n
> sql 2k for several years now (we tend to disagree often on programming
> techniques). When I asked him today how extensively he implements the sort
s
> of strategies detailed in Erland's articles he said that he rarely does an
y
> of this. I was surprised. He said that occasionally and with great restrai
nt
> he'll use a begin/commit structure. He says that if you have a system with
> many users then you have to worry about the system getting bogged down in
> transactions. I mentioned the classic example of transferring money from a
> savings account to a checking acount and what if something fails between t
he
> 2 update statements and he said that if you have a banking system where
> thousands of people are hammering away at the system all day long then usi
ng
> transactiosn in such a situation would be detrimental to performance. He
> thinks that in theory using begin/commmit and @.@.error is very good but in
> it's not very practical in the real world. I'm thinking that would be true
> if you didn't design your error handling carefully as Erland outlines. I
> would very much appreciate some feedback from the experts on this topic
> because in my opinion, not handling errors at all is a bad idea. Is my
> friend way off, somewhere in the middle or right on target?
> Thanks,
> Keith
>|||geee. and he's a db programmer?
if he doesn't use begin/commit statments in multi statement stored procs he
eventually ends up with much bigger number of transactions than with these
statements. each statement is auto committed by default, unless he uses
"implicit transactions on" setting..
http://msdn2.microsoft.com/en-us/library/ms175523.aspx
Peter|||I completely agree with Tibor... and have NEVER written any serious
application without doing proper error handling... If the data is not
important - that's one thing... but if it is used to run your business, then
you have an obligation to make sure things are good...Yes, depending on the
work you are doing, transactions might cause some locking - that is the
INTENDED way they work... They prevent one persons work from overwriting and
interfering with another..
To presumptively say that trans cause to many problems is disappointing and
lazy.
--
Wayne Snyder MCDBA, SQL Server MVP
Mariner, Charlotte, NC
I support the Professional Association for SQL Server ( PASS) and it''s
community of SQL Professionals.
"unknown" wrote:

>|||"Slow and right" beats "fast and wrong" two out of three times...
because there's always someone who doesn't care about the right answer, just
give me any answer fast.
I, for one, strongly agree with the other comments here, that good logical
transactional control and error handling is far more important than shaving
off a few milliseconds at the risk of a wrong answer.
btw, when I've dealt with folks who didn't see much value in certain SQL
technologies it was because they didn't really understand the technology -
like the data modeler who said that query path to the data didn't matter in
a database design, and sure enough, he couldn't write a basic query.
-Paul Nielsen
SQL Server MVP
"Keith G Hicks" <krh@.comcast.net> wrote in message
news:ugsl8asTGHA.1576@.tk2msftngp13.phx.gbl...
> I've been very carefully studying
> http://www.sommarskog.se/error-handling-II.html recently. I went through
> it
> some time ago before I was very familiar with working in SQL and it was
> all
> sort of mysterious to me. Now I'm finding it to be very helpful.
> Here's my issue right now: I have a former coworker who has been wroking
> in
> sql 2k for several years now (we tend to disagree often on programming
> techniques). When I asked him today how extensively he implements the
> sorts
> of strategies detailed in Erland's articles he said that he rarely does
> any
> of this. I was surprised. He said that occasionally and with great
> restraint
> he'll use a begin/commit structure. He says that if you have a system with
> many users then you have to worry about the system getting bogged down in
> transactions. I mentioned the classic example of transferring money from a
> savings account to a checking acount and what if something fails between
> the
> 2 update statements and he said that if you have a banking system where
> thousands of people are hammering away at the system all day long then
> using
> transactiosn in such a situation would be detrimental to performance. He
> thinks that in theory using begin/commmit and @.@.error is very good but in
> it's not very practical in the real world. I'm thinking that would be true
> if you didn't design your error handling carefully as Erland outlines. I
> would very much appreciate some feedback from the experts on this topic
> because in my opinion, not handling errors at all is a bad idea. Is my
> friend way off, somewhere in the middle or right on target?
> Thanks,
> Keith
>