Authentication question

Greetings from an SQL Server newbie.

We are purchasing 3rd party software with a SQL Server back end. A tech person installing SQL Server on the server insisted we use mixed mode authentication. (We are running Windows 2003 using Active Directory) We want Windows authentication (WA) but he claims it is "more complicated" to use.

His example: A shop using WA found that users running a certain process that creates and deletes temp tables did not have permission to delete tables and the process failed. The vendor had to go in and manually delete the tables.

The application uses .INI files with passwords and user names in plain text to connect to SQL Server. Our security specialist's eyes bugged out. :eek: We all think this is not good.

Is the vendor blowing us smoke? Should we insist on WA?

Thanks for your help.Depending on the package, what you want your users to do, network topography, and other issues they might have a point.

Just a few weeks ago some of the folks at a major manufacturer in Moline were having a fit about a package that had been developed internally (by a plant manager) that used SQL authentication. The central admin folks were having a fit, until they discovered that the reason the app was written that way was due to limitations in their internal network that made AD impractical. Sometimes even when you have the source code, other conditions prevent you from being able to make the changes that you'd like!

Even Microsoft came to the conclusion that SQL Authentication was the best option for those conditions, as much as it irked them to have to say that!

-PatP|||The vendor's example smacks of bogosity. Windows authenticated users, and SQL authenticated users can both be granted and denied the same set of permissions. Once a login is authenticated, there is no difference between them. The major reasons we would go with SQL authentication is for webservers. Generally, webservers run several applications (web sites), and each may need their own set of permissions on a set of databases (usually one DB per application). Windows authentication allows for only one login for the server, while SQL authentication allows each application to have its unique login.|||Exactly the problem that they were having. Pseudo-public machines force all users to share a common NT login. If you want users to have different levels of permission, you have to use SQL authentication.

The same problem applies on a more general scale to a WAN that doesn't support NetBIOS completely. Since the workstations can't authenticate over the WAN, the credentials have to be forged... Because they can't authenticate, they all get the same credentials. Same problem as before, but LOTS harder to fix!

-PatP|||So I guess sometimes it makes sense to use SQL Authentication instead of Windows Authentication. But it makes no sense to store username/passwords in an .ini file as plaintext. Perhaps it says someting about the effort put in by the vendor.|||So I guess sometimes it makes sense to use SQL Authentication instead of Windows Authentication. But it makes no sense to store username/passwords in an .ini file as plaintext. Perhaps it says someting about the effort put in by the vendor.I see that as pure idiocy, not really a database issue at all. I'm flat out allergic to storing passwords in plain text anywhere, and generally uncomfortable with storing them on PCs at all (with the exception of tools like SplashId or Password Safe that are designed for just that purpose).

-PatP|||hmmz.. pwsafe comes in handy and secure indeed. btw: it comes with an export-function to plaintext ;)|||hmmz.. pwsafe comes in handy and secure indeed. btw: it comes with an export-function to plaintext ;)I suppose that all tools have to have some flaw! ;)

-PatP

Auditing Tool

The department here is looking for a 3rd party auditing tool that can monito
r
the SQL 2000 data base for changed, deleted or added records. One utility
available is Apex SQL
Log that costs about $700.00. Anyone know of this or any other such utility
?
Thanks for everyone being there to help.Hi,
See Logexplorer from www.Lumigent.com
Thanks
Hari
SQL Server MVP
"coenzyme" <coenzyme@.discussions.microsoft.com> wrote in message
news:86F241F5-03E4-4491-ACEF-5AC5943628D8@.microsoft.com...
> The department here is looking for a 3rd party auditing tool that can
> monitor
> the SQL 2000 data base for changed, deleted or added records. One utility
> available is Apex SQL
> Log that costs about $700.00. Anyone know of this or any other such
> utility?
> Thanks for everyone being there to help.
>

Auditing Tool

The department here is looking for a 3rd party auditing tool that can monitor
the SQL 2000 data base for changed, deleted or added records. One utility
available is Apex SQL
Log that costs about $700.00. Anyone know of this or any other such utility?
Thanks for everyone being there to help.
Hi,
See Logexplorer from www.Lumigent.com
Thanks
Hari
SQL Server MVP
"coenzyme" <coenzyme@.discussions.microsoft.com> wrote in message
news:86F241F5-03E4-4491-ACEF-5AC5943628D8@.microsoft.com...
> The department here is looking for a 3rd party auditing tool that can
> monitor
> the SQL 2000 data base for changed, deleted or added records. One utility
> available is Apex SQL
> Log that costs about $700.00. Anyone know of this or any other such
> utility?
> Thanks for everyone being there to help.
>

Auditing Tool

The department here is looking for a 3rd party auditing tool that can monitor
the SQL 2000 data base for changed, deleted or added records. One utility
available is Apex SQL
Log that costs about $700.00. Anyone know of this or any other such utility?
Thanks for everyone being there to help.Hi,
See Logexplorer from www.Lumigent.com
Thanks
Hari
SQL Server MVP
"coenzyme" <coenzyme@.discussions.microsoft.com> wrote in message
news:86F241F5-03E4-4491-ACEF-5AC5943628D8@.microsoft.com...
> The department here is looking for a 3rd party auditing tool that can
> monitor
> the SQL 2000 data base for changed, deleted or added records. One utility
> available is Apex SQL
> Log that costs about $700.00. Anyone know of this or any other such
> utility?
> Thanks for everyone being there to help.
>

Attn: MS Engineers - 3rd Posting - KeepTogether not working

I originally posted this on 10/18 and again on 10/19 but received no response
so I am trying again.
I have a main report that contains a table. One detail row of that table
calls to a subreport (which also contains a table). When the entire report
displays, if the main report and subreport data will all fit on one page it
will do so, but if not, the main report goes part of the way down a page
(leaving up to 3/4 of the page blank), then breaks to a new page to display
the subreport data. It seems to try and keep the subreport data table
together more than the main report table. I have KeepTogether set to False on
both tables in the main report and the subreport. The way it is now, the
display format is unacceptable. Please offer any ideas.I donâ't know if this helps, but I ran into a similar problem.
Problem â' Detail is too large for a single page
Table herders get blown off the page and do not show on subsequent pages
Resolution:
Copy your table header row
Insert a new detail row below the header and after your first detail row
Paste the dummy table header row into the new detail row
Change the visible property on the dummy table header row to something like
the following
o =iif(ReportItems!TableHeaderField.Value=nothing, false,true)
This should fix your issue if I understand it correctly..
Good luck, AHH

Attaching 6.5 db files

Hello everyone,
I'm in a situation with a 3rd party where they have 3 .dat files (no log fil
es) from a SQL 6.5 database. These files were located on a backup tape from
2001. The client would like to make this database operational again. The
master.dat file was not rec
overable, nor was the log file. Is there any way to "attach" these files so
we can ultimately upgrade to SQL 2000? Any input would be appreciatedYou would need a 6.5 installation to begin with. Then you would either use
LOAD ("restore") if the DAT file is a backup file (produced with DUMP) or
use DISK REINIT and DISK REFIT if it is a database file (which I'm sure
requires all the database devices that constituted the database).
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
"Mike" <mjucht@.neb.rr.com> wrote in message
news:E27B27A7-F299-473A-A816-42C757AE8330@.microsoft.com...
> Hello everyone,
> I'm in a situation with a 3rd party where they have 3 .dat files (no log
files) from a SQL 6.5 database. These files were located on a backup tape
from 2001. The client would like to make this database operational again.
The master.dat file was not recoverable, nor was the log file. Is there any
way to "attach" these files so we can ultimately upgrade to SQL 2000? Any
input would be appreciated|||Mike
You can not attach SQL 6.5 databases, it was not a feature available at that
time.
If you have the dat files you may be able to restore the database to a SQL S
erver 6.5 installation and then upgrade. Although you only have .dat files y
ou may have the logs, in 6.5 you do not have to seperate the data and logs s
o the .dat files may contai
n both.
However even if you do have the entire database in the files you have, you s
till will not be able to restore the database unless you build it exactly li
ke it was. What this means is that say you had a 300mb 6.5 database that was
created as 100mb and expan
ded by 100mb twice. You would need to create an empty database in exactly th
e same way before you could restore it.
The best way to restore a 6.5 database is to have the output from sp_help_re
vdatabase available. I don't suppose you have that do you?
Hope this helps
John|||I'm reading up on the DISK REINIT command and it states the SIZE parameter m
ust be identical to how the device was originally created. Is there any way
to tell how the device was originally created without the master.dat? I'm
afraid the answer is "no" b
ut if you have any ideas I'd appreciate them.
Thanks,
Mike
-- Tibor Karaszi wrote: --
You would need a 6.5 installation to begin with. Then you would either use
LOAD ("restore") if the DAT file is a backup file (produced with DUMP) or
use DISK REINIT and DISK REFIT if it is a database file (which I'm sure
requires all the database devices that constituted the database).
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
"Mike" <mjucht@.neb.rr.com> wrote in message
news:E27B27A7-F299-473A-A816-42C757AE8330@.microsoft.com...
> Hello everyone,
files) from a SQL 6.5 database. These files were located on a backup tape
from 2001. The client would like to make this database operational again.
The master.dat file was not recoverable, nor was the log file. Is there any
way to "attach" these files so we can ultimately upgrade to SQL 2000? Any
input would be appreciated|||You have the physical file size, and can go on that!
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
"Mike" <mjucht@.hotmail.com> wrote in message
news:ECC5EA3A-2283-45A5-87A6-F29156BD01B4@.microsoft.com...
> I'm reading up on the DISK REINIT command and it states the SIZE parameter
must be identical to how the device was originally created. Is there any
way to tell how the device was originally created without the master.dat?
I'm afraid the answer is "no" but if you have any ideas I'd appreciate them.
> Thanks,
> Mike
> -- Tibor Karaszi wrote: --
> You would need a 6.5 installation to begin with. Then you would
either use
> LOAD ("restore") if the DAT file is a backup file (produced with
DUMP) or
> use DISK REINIT and DISK REFIT if it is a database file (which I'm
sure
> requires all the database devices that constituted the database).
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
>
> "Mike" <mjucht@.neb.rr.com> wrote in message
> news:E27B27A7-F299-473A-A816-42C757AE8330@.microsoft.com...
(no log
> files) from a SQL 6.5 database. These files were located on a backup
tape
> from 2001. The client would like to make this database operational
again.
> The master.dat file was not recoverable, nor was the log file. Is
there any
> way to "attach" these files so we can ultimately upgrade to SQL 2000?
Any
> input would be appreciated
>
>