IWETHEY v. 0.3.0 | TODO
1,095 registered users | 0 active users | 0 LpH | Statistics
Login | Create New User
IWETHEY Banner

Welcome to IWETHEY!

New Two tacts...
Using the SELECT INTO or BULK INSERT will bypass transactions if you have the specific database configured for it (under options for Select Into /Bulk Copy Option). And yes, the SELECT INTO is also another way to bypass the transaction log into a table.

Other than that, the best way to generally bypass the problem is to make sure and use temporary tables for any intermediate table writes. When you drop the temp tables, the associated transactions will also be dropped.
New Probably shouldn't fight it though
A lot of people look at transactions as a problem on SQLServer and initially try as they might to skirt around them. Generally speaking, though, if you are trying to fight Transactions, you are just fighting the innate nature of the architecture.

Best to work them than against them.
New Havnt messed with SQLServer yet, question
transaction logs are both usefukl for debugging and transaction rollbacks? If so work with them.
thanx,
bill
will work for cash and other incentives [link|http://home.tampabay.rr.com/boxley/resume/Resume.html|skill set]

questions, help? [link|mailto:pappas@catholic.org|email pappas at catholic.org]
New SAS rears its ugly head...

Thing is, we're accessing this puppy through SAS, the database\r\nappears as a (fairly) standard SAS library, access is through ODBC. So\r\nmy own control through code to what's going on with the table itself is\r\nrelatively limited. I'm also not able to add/drop indices on the SQL\r\nServer tables from within SAS, so a number of options of r easing the\r\nupdate process are somewhat foregone.

\r\n\r\n

One option, of course, is that there isn't a good solution to this\r\nand we'll either have to suffer or look for an alternate solution.

\r\n\r\n

I'll also see what I can find out about the SAS side of affairs and\r\nwhat sort of requests it's generating for the DB.

\r\n
--\r\n
Karsten M. Self [link|mailto:kmself@ix.netcom.com|kmself@ix.netcom.com]\r\n
[link|http://kmself.home.netcom.com/|http://kmself.home.netcom.com/]\r\n
What part of "gestalt" don't you understand?\r\n
[link|http://twiki.iwethey.org/twiki/bin/view/Main/|TWikIWETHEY] -- an experiment in collective intelligence. Stupidity. Whatever.\r\n
\r\n
   Keep software free.     Oppose the CBDTPA.     Kill S.2048 dead.\r\n[link|http://www.eff.org/alerts/20020322_eff_cbdtpa_alert.html|http://www.eff.org/alerts/20020322_eff_cbdtpa_alert.html]\r\n
New SAS used to be able to shell out - run a "Load.Bat"?
New "Tacks", actually. HTH!
     MS SQL Server: Logs & performance tuning? - (kmself) - (9)
         Two tacts... - (ChrisR) - (5)
             Probably shouldn't fight it though - (ChrisR) - (1)
                 Havnt messed with SQLServer yet, question - (boxley)
             SAS rears its ugly head... - (kmself) - (1)
                 SAS used to be able to shell out - run a "Load.Bat"? -NT - (CRConrad)
             "Tacks", actually. HTH! -NT - (CRConrad)
         Import vs. Load? BCP? - (gdaustin)
         Re: MS SQL Server: Logs & performance tuning? - (orion)
         Non-intuitively, you need to set the backup strategy. - (rickw)

Same LRPD time, same LRPD channel.
90 ms