By default the sa account has a server role of system administrator. For non sql users this means it gets god rights. The best security practice is to remove these rights, making the sa account useless.
Then setup another account with a funky name that know one knows. As far as devolpers, if your in an NT shop USE NT SECURITY, then you don't have to worry about anyone knowing passwords.
Even if you can't do this you can deny access to the part of the system that makes the sql server vunarable. I'm assuming that this virus calls xp_cmdshell, which gives you access to the command prompt. As well all eXtended stored procs should be disabled for the sa account.
The sa account is not the same thing as root in Linux. It can't be deleted, but it's rights can be reduced like any other account in the system.
Hey have you ever tried to do transactionS in MySQL or have a database that is over a 10 gigs in MySQL. MS SQL Server is not the problem here and you know it, it is bad management or bad sysadmining.
Why the heck is this comment monitored so high, enterpise level dba's no that MySQL is not ready for mission critical apps, at least ones that are fairly to really complex.
The client is the one that needs the information in easier to read form, not the server.
Relational databases are fast, dependable, and are well proven. The data storage that they provide is very adequate for most situations, if not all.
What really needs to happen is SQL needs to evolve to include XML, and better support for some other situations that constantly arise when writing complex queries.
I wish that the top clause could be used on a join stament.
left join top 1 some_table st ( ot.pk = st.fk ) with order by st.some_column.
Or that there was some syntax for querying out trees of data. Or there was a way to embed code in the joins that could analyze what had been joined at each loop. The data is stored fine in a relational database, sometimes SQL doesn't have the power to extract in a simple manner. I'm sure you can think of many other things that SQL could do a lot better.
Looking at one to many or many to many relationships in the standard two dimensional data set is a pain. Especially when you have several joins that can duplicate data. Cold fusion ( I know it sucks ) has a feature that allows you to query a result set, which makes extracting the data you need a little eaiser, but XML would make this a mute point.
Microsoft is developing an XML extension that will return the data in XML for SQL server. The bigger issue is that ODBC needs to do it before they (MS) do so that we don't get stuck using Microsoft XML over OLE DB, which means no Linux support. You can read about MS solution at http://www.microsfot.com/sql.
Looking at MS solution, it is still too complicated, because the SQL language does not allow you to direct the XML output. As well if foreign keys are setup it shouldn't need them, as well the join statements should be more then adequate to describe how the XML should be formated.
Another aspect is update/insert/bulk inserts. This could make doing updates to linked tables easier. As well as inserting complex structures of data. Also, it could be used to check data before it got inserted into the db and failed.
Data transfers would be much nicer as well. Taking what is one to many relationships in you database, and trying to make them horizontal instead of vertical is a real pain in the ass. It is also much slower usually because of the extra joining needed.
OLAP applications could stand to benifits as well. OLAP produces data in with multiple dimensions. Usually this is accomplished by
having binary data formats that are specific to vendors, now multi-dimensional data can be treated the same as any other result set.
I think we are a good year or two away from there being good XML support for databases, but it will increase application performance as front end guys and gals can issue less queries to the database to get the data they need, a in more logical fashion as well.
If you get overexposed to radiation, you can form cancer.
If the isotope did target the wrong cell, could it cause cancer in it, worsening the problem?
Slashdot Mirror
By default the sa account has a server role of system administrator. For non sql users this means it gets god rights. The best security practice is to remove these rights, making the sa account useless.
Then setup another account with a funky name that know one knows. As far as devolpers, if your in an NT shop USE NT SECURITY, then you don't have to worry about anyone knowing passwords.
Even if you can't do this you can deny access to the part of the system that makes the sql server vunarable. I'm assuming that this virus calls xp_cmdshell, which gives you access to the command prompt. As well all eXtended stored procs should be disabled for the sa account.
The sa account is not the same thing as root in Linux. It can't be deleted, but it's rights can be reduced like any other account in the system.
Hey have you ever tried to do transactionS in MySQL or have a database that is over a 10 gigs in MySQL. MS SQL Server is not the problem here and you know it, it is bad management or bad sysadmining. Why the heck is this comment monitored so high, enterpise level dba's no that MySQL is not ready for mission critical apps, at least ones that are fairly to really complex.
The client is the one that needs the information in easier to read form, not the server.
Relational databases are fast, dependable, and are well proven. The data storage that they provide is very adequate for most situations, if not all.
What really needs to happen is SQL needs to evolve to include XML, and better support for some other situations that constantly arise when writing complex queries.
I wish that the top clause could be used on a join stament.
left join top 1 some_table st ( ot.pk = st.fk ) with order by st.some_column.
Or that there was some syntax for querying out trees of data. Or there was a way to embed code in the joins that could analyze what had been joined at each loop. The data is stored fine in a relational database, sometimes SQL doesn't have the power to extract in a simple manner. I'm sure you can think of many other things that SQL could do a lot better.
Looking at one to many or many to many relationships in the standard two dimensional data set is a pain. Especially when you have several joins that can duplicate data. Cold fusion ( I know it sucks ) has a feature that allows you to query a result set, which makes extracting the data you need a little eaiser, but XML would make this a mute point.
Microsoft is developing an XML extension that will return the data in XML for SQL server. The bigger issue is that ODBC needs to do it before they (MS) do so that we don't get stuck using Microsoft XML over OLE DB, which means no Linux support. You can read about MS solution at http://www.microsfot.com/sql.
Looking at MS solution, it is still too complicated, because the SQL language does not allow you to direct the XML output. As well if foreign keys are setup it shouldn't need them, as well the join statements should be more then adequate to describe how the XML should be formated.
Another aspect is update/insert/bulk inserts. This could make doing updates to linked tables easier. As well as inserting complex structures of data. Also, it could be used to check data before it got inserted into the db and failed.
Data transfers would be much nicer as well. Taking what is one to many relationships in you database, and trying to make them horizontal instead of vertical is a real pain in the ass. It is also much slower usually because of the extra joining needed.
OLAP applications could stand to benifits as well. OLAP produces data in with multiple dimensions. Usually this is accomplished by
having binary data formats that are specific to vendors, now multi-dimensional data can be treated the same as any other result set.
I think we are a good year or two away from there being good XML support for databases, but it will increase application performance as front end guys and gals can issue less queries to the database to get the data they need, a in more logical fashion as well.
If you get overexposed to radiation, you can form cancer. If the isotope did target the wrong cell, could it cause cancer in it, worsening the problem?