We want to use SQL Mail over the Internet. What problems might we
encounter?
In some cases, SQL Server hangs when you use SQL Mail with a profile
configured to use a Post Office Protocol (POP) 3 Internet mail server.
Apparently, a bug in the Windows NT Service Pack 3 (SP3) version of MAPI32.DLL
causes this problem but only if you've set SQL Server's priority boost to 1.
Microsoft has a SQL Server hotfix that solves this problem. However, because
hotfixes aren't fully regression tested (and can create new bugs), Microsoft
conservatively suggests leaving the priority boost set to 0 if you're
encountering this problem.
I ran DBCC NEWALLOC on my database and received the following error
message on two system tables, sysprocedures and syscomments:
TABLE: sysprocedures OBJID = 5
INDID=1 FIRST=88 ROOT=164803 DPAGES=9076 SORT=0
Msg 2558, Level 16, State 2, Server Tom
Extent not within segment: Object 5, indid 1 includes extents on
allocation page 414208, which is not in segment 0.
SQL Server Books Online (BOL) says that to fix the
system tables, I must restore from a clean backup, but I don't have a clean
backup. Can I fix this problem another way?
We think you'll find the following TechNet information about nonclustered index pages useful. To find the article in TechNet, search on error 2558, and choose SQL Server Troubleshooting Guide in the result set. Read the whole article, and then reread this section to see how to fix your problem.
Nonclustered index pages. The error occurred on the index of
a user table. The error can be cleared by dropping and re-creating the index.
Creating a clustered index causes all nonclustered indexes to be rebuilt as
well. Therefore, if 2558 errors are occurring on several indexes on the same
table, you can create a clustered index on that table to clear all these errors.
Another approach is to try using Database Consistency Checker (DBCC) reindex to
rebuild the index in question.
What's the best way to extract data from SQL Server in realtime? I work
for a company that needs to store manufacturing data (e.g., material and receipt
information) in SQL Server and to extract this information whenever someone
adds, updates, or deletes a record. I've considered triggers (i.e., extracting a
record to a sequential file), but do you know any alternatives that are
event-driven and realtime?
Your options are the trigger approach or the API route. You need to base
your decision on functional business requirements, transaction volume, and so
on. The API approach gives you more flexibility to batch by time or number of
transactions, but it requires extra coding and the extra maintenance that goes
with API routines. For starters, you might want to think about whether you need
receipt information in realtime. In a shop floor environment, you probably need
receipt information only if people are waiting for parts. If this situation
occurs frequently, you're justified in wanting realtime receipt information.
You've probably discovered that you can't write directly to a sequential
file, but you can work around that limitation by writing your file output to a
table and then using bulk copy program (bcp) to extract the data. You
might want to consider implementing replication--set the timing to every
second or two, or every x transactions. If you use a second server on
site, pulling reports off the subscriber is simple and takes the trigger load
off the server; but it adds the overhead associated with replication. You need
to experiment to see what works best for you.
Can you reference more than 16 tables in one query?
No, SQL Server can't reference more than 16 tables in one query. Most
queries don't need to exceed that limit, but from time to time you'll bump your
head against that ceiling. We recently ran across a tip in a public newsgroup
discussion that might come in handy if you ever hit this barrier: You can use
trace flag 105 to reference more than 16 tables with one query.
But be warned: Microsoft doesn't support trace flags. If you want to use a
trace flag, be cautious and thoroughly test it in your environment before you
deploy it in a production environment.
The good news is that you probably won't have to wait long for a legitimate,
Microsoft-sanctioned solution, because Microsoft says that SQL Server 7.0 will
support up to 32 tables in a SELECT statement. Another limitation we're happy to
see scotched is the 64KB maximum source filesize for stored procedures.
Prev. page
[1]
2
3
4
next page 
