Wednesday, March 21, 2012
Mixing SQL Server and MSDE and authentication
authentication, and specify a password for 'sa'.
I recently had someone install it on a system that already had SQL Server
installed.
On that system, we could not connect to the named instance using the "sa"
user and password specified in the installer. Using ODBC, we kept getting
the error 18452 - Login failed for user 'sa'.
How does the presence of SQL Server affect this? Does the 'sa' password for
the SQL Server default instance take precedence?
hi,
"JJ" <jjjj@.nospam.com> ha scritto nel messaggio
news:uAPJ05LGEHA.2732@.tk2msftngp13.phx.gbl...
> We install MSDE2000 under a named instance and with SQL Server
> authentication, and specify a password for 'sa'.
> I recently had someone install it on a system that already had SQL Server
> installed.
> On that system, we could not connect to the named instance using the "sa"
> user and password specified in the installer. Using ODBC, we kept getting
> the error 18452 - Login failed for user 'sa'.
> How does the presence of SQL Server affect this? Does the 'sa' password
for
> the SQL Server default instance take precedence?
>
it shoul'd really not...
all specified settings are instance specific, the only difference is that
the 1st instance (default) will listen to default TCP/IP port 1433, while
all other ubsequent instances will pass throught UDP port 1434 if they have
been set to dinamically retrieve the port number... but this another
story...
if you can reproduce the problem and are "sure" [ =;-) ] that the MSDE
instance has been installed specifying the SECURITYMODE=SQL parameter, you
are wellcome to open a case with Microsoft PSS...
thank you
Andrea Montanari (Microsoft MVP - SQL Server)
http://www.asql.biz/DbaMgr.shtmhttp://italy.mvps.org
DbaMgr2k ver 0.7.0 - DbaMgr ver 0.53.0
(my vb6+sql-dmo little try to provide MS MSDE 1.0 and MSDE 2000 a visual
interface)
-- remove DMO to reply
|||hi again,
anyway, try checking the HKLM\Software\Microsoft\Microsoft SQL
Server\Instance Name\MSSQLServer\LoginMode registry key... it shoul'd be 2
or 0 for mixed mode authentication...
Andrea Montanari (Microsoft MVP - SQL Server)
http://www.asql.biz/DbaMgr.shtmhttp://italy.mvps.org
DbaMgr2k ver 0.7.0 - DbaMgr ver 0.53.0
(my vb6+sql-dmo little try to provide MS MSDE 1.0 and MSDE 2000 a visual
interface)
-- remove DMO to reply
|||That's the strange part - I did check that in the registry and it was set to
2, so I tried setting it to 0 (then stopped and restarted the MSDE instance)
and got the same error.
Unfortunately, I can't check it again because we ended up just using SQL
Server and uninstalling MSDE for the user with the problem. (It was
actually a mistake for the user to have done the install with MSDE because
usually if they have SQL Server already, we want them to just use that. I
can't think of a good reason for an end user to have both SQL Server and
MSDE installed on the same system. But I was curious to find out whether or
not it should have worked.)
It may indeed have been the dynamic port issue - I did not check the client
configuration to see if it was trying to go to a specific port (i.e. 1433).
But I would have thought it just wouldn't have connected since the server
name contained the instance name.
"Andrea Montanari" <andrea.sqlDMO@.virgilio.it> wrote in message
news:c4ju2l$2h7scp$1@.ID-207518.news.uni-berlin.de...
> hi again,
> anyway, try checking the HKLM\Software\Microsoft\Microsoft SQL
> Server\Instance Name\MSSQLServer\LoginMode registry key... it shoul'd be 2
> or 0 for mixed mode authentication...
> --
> Andrea Montanari (Microsoft MVP - SQL Server)
> http://www.asql.biz/DbaMgr.shtmhttp://italy.mvps.org
> DbaMgr2k ver 0.7.0 - DbaMgr ver 0.53.0
> (my vb6+sql-dmo little try to provide MS MSDE 1.0 and MSDE 2000 a visual
> interface)
> -- remove DMO to reply
>
Friday, March 9, 2012
Missing rows when viewing data in Report Builder. What gives?
When I build an ad-hoc report against this model, I end up with 2 different scenarios.
The first scenario is as follows:
I select a single attribute from the entity "Unit_Number" and add it to my report. I run the report and the footer of the report displays 10576 rows. I then export the report to Excel and when I check the actual number of records, there are only 7652 rows. I have confirmed the correct number of records by writing a simple SQL query which also generates a result with 10576 rows.
The same results are achieved if I add the attribute "Type_Code" from the "Unit_Type" table IF the Type_Code is part of the "Unit" group. To be clear, if I first add an attribute from the Unit table and then add an attribute from the Unit_Type table, my report has a single group and both entities belong to that group. This format will never give me correct number of records.
One more important piece of info... I have validated that there are absolutely NO duplicate records in my result set. All 10575 rows are unique.
The second scenario is as follows:
Rather than first selecting from the Unit table, I select "Unit_Type" from the "Unit_Type" table and then I add the attribute "Unit_Number" from the Unit table. Report Builder creates 2 groups when I set up the report this way.
The result when I run this report is 10576 rows when I import my report using this scenario into Excel! This is correct!
Question
So, why does Report Builder generate an incorrect result set unless attributes from both entities are included in the report and the attributes are in seperate groups? This makes no sense to me and will be extremely difficult to explain to our users.
I would really appreciate any feedback on this.
Scott
Are you running Service Pack 1? We fixed a bug with the wrong number of rows in Report Builder.|||I have the same problem, the solution was not to use Report Builder because it give you wrong results , its not a question of service pack or version, if you have a tool that don't give correct result's can you tell your client, "sorry but you have order $100.000 of product that you have in stock call microsoft they will give your money back"