|
Are you looking for data that occurred before TODAY or NOW? edit: Oh, you had < when you needed >? Sounds like your boss could work as a bug tester at my office. "There's a bug "
|
# ¿ Nov 1, 2007 20:37 |
|
|
# ¿ Apr 23, 2024 16:16 |
|
Victor posted:Last time I tried SQL Prompt, I found that it requires you to type ctrl-space or something to activate the dropdown (or the dropdown would appear way too often), wouldn't autocomplete after pressing space, and other such annoyances. Maybe I've just acclimated to VS2005's intellisense, but I really like it, more than any other intellisense I've used. Oh, I don't think SQL Prompt does autocompletion for INFORMATION_SCHEMA, which I use a lot. Regarding nulls, as mentioned by Victor, they always evaluate to unknown. "null is null" is true, of course, but "null = null" is unknown. Anything plus null is null as well. This can be confusion if you don't know the behavior. The main problem is expecting "null = null" to work and using it in join or where clause. code:
|
# ¿ Nov 2, 2007 19:21 |
|
I just got a pretty hosed up email from work. We're making some pretty big cutbacks (a lot of people lost their job, and it's a small company), so I'm looking for ideas to help out. We have a lot of in-house toolkits that my coworker and I have developed to make our lives easier. One of them is a pretty powerful database abstraction layer for MSSQL 2005, 2008 and 201x. It's a versioned database abstraction layer that emits and consumes only XML, handles all table relationships automatically (including bridge objects - eg Object A can be associated with Object B through Object C), with a Web Service and .NET API. It also provides events (web service calls, email, etc), has tons of filtering options, and can attach to any number of databases. We use it to lessen the annoyance of an industry standard database, and it's actually faster than even well optimized queries most of the time. The feature list is very long, and the amount of things it does for us is crazy. I'm considering talking to the CEO about packaging it as a distinct product. Of all you SQL people, does anyone think this is a sellable product for use as middleware? If you could work with an annoying database through well defined XML based objects, would that help you? I'll be happy to field any questions here if appropriate, via PM or AIM, or by email. I'm not looking for actual buyers, I'm just curious if such a tool could be marketed in the near future. I feel bad even posting this, but since I have to take a 10% pay cut just to keep my job, I think it's worth probing for interest.
|
# ¿ Mar 4, 2009 08:20 |
|
Yeah, I'm looking around at other products right now. This sucks, I don't know what to do if the company I've spent 10 years at goes under.
|
# ¿ Mar 4, 2009 18:49 |
|
Touche. I haven't found any competing products yet that do anything close to what ours does yet. I'm not sure if that's good or bad, since it makes it hard to determine whether there's a market or not.
|
# ¿ Mar 4, 2009 19:06 |
|
You can map them through a third table if you can't update table B.code:
|
# ¿ Mar 6, 2009 22:11 |
|
It looks like the problem is SQL Server can't open the backup file. Set the permissions for YourComputerName\NetworkService or Everyone to allow read or full access for that .bak file.
|
# ¿ Mar 10, 2009 22:27 |
|
Apparently it doesn't. Give SYSTEM full permissions to the file, or Network Service, depending. Neither are covered by "Users".
|
# ¿ Mar 10, 2009 22:45 |
|
Ah, that makes sense since you don't appear to be using the default SQL data folder (which is fine). I just assumed you were restoring to a folder SQL had access to.
|
# ¿ Mar 10, 2009 22:54 |
|
Victor posted:Try/Catch helps some, but I honestly do not know if the transaction will be rolled back if your CATCH block is hit. I advise you to test this stuff. That's how I figure out a lot of things... edit: Unless you rollback the tran in there. Here's a safer pattern: code:
SLOSifl fucked around with this message at 16:45 on Mar 12, 2009 |
# ¿ Mar 12, 2009 16:40 |
|
Are you trying to update existing rows or is allPosts empty? If you're just dumping a single column from a table into allPosts (which is empty), then you need DISTINCT after the SELECT.
|
# ¿ Mar 17, 2009 03:31 |
|
INSERT INTO WhateverTable ( Column1, Column2, Column3 ) SELECT [Column1], [Column2], [Column3] FROM INSERTED
|
# ¿ Mar 17, 2009 16:18 |
|
No, there's no UPDATED pseudo-table. It's always called INSERTED. Yes, it'll work on a batch operation.
|
# ¿ Mar 17, 2009 16:24 |
|
I'm a bit of a SQL-CLR whore, so I'm sure there's a pure T-SQL method I'm ignoring. If you want to just use T-SQL then you can write a SP that does basically the same thing. Or Google for T-SQL string split and see where that gets you. You could make a CLR Stored Procedure that runs your query, parses the [names] column and adds the values to a List<string>, returning the name using SqlContext.Pipe.Send (SqlDataRecord) if the list didn't already contain that name. code:
SLOSifl fucked around with this message at 21:20 on Apr 30, 2009 |
# ¿ Apr 30, 2009 21:13 |
|
Triple Tech posted:And yet neither of you mention how that type of data is set up poorly for relational databases? If you frequently need to pull unique names from that mess, then yes, you're better off rethinking it. One option would be to make a surrogate table and throw a trigger on your existing one. On insert, update or delete, update your normalized table. Remember that the pseudo-table in *both* insert and update triggers is called INSERTED and you'll be fine. My CLR solution posted on the previous page will get you your list and should be basically working. 40,000 rows isn't a lot. At least with a CLR option, you're processing the data before it ever leaves the server. Doing it client side is a perfectly workable option as well, as long as you don't have to do it that often.
|
# ¿ May 1, 2009 04:55 |
|
SQL Express is great. Other than having an integrated SQL Agent for job scheduling and 4GB database file size limits, it's an extremely good free database with great tools.
|
# ¿ May 7, 2009 19:53 |
|
|
# ¿ Apr 23, 2024 16:16 |
|
Anaxandrides posted:I can say that this is 100% possible to write in MSSQL. It's possible to write many, many things that you should not write, though, and this is one of them. You're much better off having multiple UPDATE statements with differing WHERE clauses than having one massive UPDATE that selectively updates based on the value in the row -- isn't that what WHERE clauses are for? What is the concern about updating columns that aren't changing? The only case where that could theoretically matter is if you update rows that don't need any updates at all, but even that can be offset by an efficient WHERE clause. Just update all the columns if any of them have changed...or do you have triggers on the table that care if certain columns were touched? code:
SLOSifl fucked around with this message at 13:12 on Sep 9, 2014 |
# ¿ Sep 9, 2014 13:05 |