books on odbc

At one point I had the odbc 3.5 developers guide but I had to leave that
behind as a result of a layoff.
Now after several years I find I'm getting back into odbc but when I
search I find that all books on odbc are out of print. Some are still
available like the 3.5 developers guide but hard to get.
is there a good book on odbc programming that is current?
Only thing I know of that is current is online at msdn. You
can use the ODBC Programmer's Reference which is at:
http://msdn.microsoft.com/library/en...his_manual.asp
-Sue
On Wed, 31 Mar 2004 09:31:12 -0700, William Kossack
<kossackw@.njc.org> wrote:

>At one point I had the odbc 3.5 developers guide but I had to leave that
>behind as a result of a layoff.
>Now after several years I find I'm getting back into odbc but when I
>search I find that all books on odbc are out of print. Some are still
>available like the 3.5 developers guide but hard to get.
>is there a good book on odbc programming that is current?
>

books on odbc

At one point I had the odbc 3.5 developers guide but I had to leave that
behind as a result of a layoff.
Now after several years I find I'm getting back into odbc but when I
search I find that all books on odbc are out of print. Some are still
available like the 3.5 developers guide but hard to get.
is there a good book on odbc programming that is current?Only thing I know of that is current is online at msdn. You
can use the ODBC Programmer's Reference which is at:
http://msdn.microsoft.com/library/e...this_manual.asp
-Sue
On Wed, 31 Mar 2004 09:31:12 -0700, William Kossack
<kossackw@.njc.org> wrote:

>At one point I had the odbc 3.5 developers guide but I had to leave that
>behind as a result of a layoff.
>Now after several years I find I'm getting back into odbc but when I
>search I find that all books on odbc are out of print. Some are still
>available like the 3.5 developers guide but hard to get.
>is there a good book on odbc programming that is current?
>sql

Bookmark Lookup

Fellow Developers

i have a query that has joins of tables with huge data (more than 2G of records per table). the execution plan shows me the 80% of the execution is on a "Bookmark Lookup" on the biggest table. Does anyone have clue how can I optimize this query? other than using covering indexes...

best regards

Jeries Shahin wrote:

Other than using covering indexes...

Well, if you know the answer already....

Seriously, you need to understand how indexes in SQL Server work (you may already, so here is the short version.) The nonclustered index uses the key of the clustered index rather than keeping a pointer to the physical page. Of course, this is great almost all of the time, but can be a costly operation at times.

Are you using any hints? And what join operators are being used? That is a lot of data (assuming 2G = 2 GB and not 2 grand :) and I would have assumed it would do a hash join, unless this is doing a merge join. Posting the output of showplan_text would be a good place to start:

set showplan_text on
go

select ...
go

set showplan_text off
go

And what version of SQL Server are you on? The new INCLUDE clause on the CREATE INDEX statement could actually be the ticket. It gives you a covering index without the overhead of including data you aren't using for searching on in the B-Tree (only the leaf nodes are affected)

|||

Why don't you want to use a covering index. Thats like saying I want my car to go but I don't want to use gas. If you want performance from a relational DB system you need to use the right indexes.

I agree that the "include" option in SQL 2005 maybe an option.

|||

Using a covering index can be really costly if the index keys are really large, so it might not be a good idea in 2000 or earlier to cover an index. We don't know his usage pattern and that is a lot of data (again assuming that G means GB :) This query might only be executed once a day/week/month. There may be thousands of modifications a minute on the table.

It might even be that a reporting database/warehouse is in order.

|||

I agree but to some extent if the performance isn't what is required, then something has to be done and there are a number of options covering indexing being on of them, redesign being another.

One always has to balance out their performance needs. This gets much more complex when doing DSS stuff on an OLTP system. ideally they should be mutually exclusive.

Blocking sa user

Hi All,
I have a hypothetical scenario. I have few developers who all know the sa password. I want to block one developer from accessing the SQL server eventhough he knows the sa password.

Do we have any mechanism in SQL Server 2000 to block client based on the IP address of the client?

SQl Server is installed on Windows 2000 server. It uses SQL Server & Windows authentication.

Regards,
AnandChange the sa password|||Thanks for the reply.
I know that would be the best alternative :)
But currently I am not in a position to change it immediately.

Can you suggest something else

Regards,
Anand|||sa login is built-in login as well as assigned sysadmin fixed server role. You can change sa password, but if someone knows the password he/she can login the SQL Server.

Use mixed mode security or give separate SQL Login to the developers with the db_owner or db_ddladmin database role, according to your requirement.|||How about VPN, router settings, IP or MAC filtering?|||You can filter ports to keep an IP address from making any connection to a SQL Server database, but that's rather drastic for limiting a developer. There are solutions to this problem, but all of the ones that I can think of require intimate knowledge of the problem... I don't know of any generic answer to this kind of problem.

-PatP|||change the f'n sa password

sa shouldn't be used...some writers have even suggested creating a very strong password...write it down, put it in a safe and never use it..and create a new, "unknown" login that has sa rights|||change the f'n sa password

sa shouldn't be used...some writers have even suggested creating a very strong password...write it down, put it in a safe and never use it..and create a new, "unknown" login that has sa rights

Yep. First thing I do. Select newid() (on a different server). Copy and paste results into the install screen. Forget about it. Never use sa for anything.

Regards,

hmscott|||Yep. First thing I do. Select newid() (on a different server). Copy and paste results into the install screen. Forget about it. Never use sa for anything.

Regards,

hmscott

Humm... really unique password..! :rolleyes: