I believe the security in.NET is a sandbox system, but it's also flexible. Apparently there's a way for your applications to define custom actions and then users can grant or deny permission to perform that action. Seems like a pretty good idea compared to the sandbox being completely defined by the platform/language.
Your experience was completely different than mine. Several months ago I set up an account, even used it limited places on the net, and I've gotten maybe 5 spams total. Even the ones I did receive have been placed directly into the Junk Mail folder (browser) or Bulk Mail (Outlook Express). I'd say their anti-spam initiative has done pretty well, I watch friends with netscape mail fill up with over 60 spams a day.
A lot of the applications I've written have been Access/VB front ends with Access/SQL backends. (Yea, I know what most of the slashdot community thinks about those development tools but that's a different argument...). I've seen more RAM on a server *drastically* improve performace, for example a process that takes 10-15 seconds become almost instant. These are custom apps, where the customer pays per hour about as much as it costs for like what, 256 megs of RAM (don't know current prices but it IS cheap). So if an app is performing slowly, you can either rewrite the logic, introducing new bugs, spending lots of hours coding, testing, building releases, etc., or sometimes you can pop some RAM in and the problem goes away. This isn't to say that all performance issues are handled by RAM, sometimes code just sucks, but this has been the solution on numerous products I've worked with.
And after we've convicted the Talibans, who give shelter to bin Laden, what next? There seems to be plenty of evidence pointing to bin Laden. Bush has already declared we will attack those who aid the terrorists. So we'll have to attack somehow, and a ground war sure won't be pretty.
I think we should bomb the hell out of Afghanistan, at least the main areas that the Talibastards inhabit, and turn it into a nice vacation resort for the civilized people of the world.
ADO, OLE DB, ODBC and DB-Library all expose the functionality of cursors through recordsets. From my experience recordset operations have to be one of the most common operations of database applicaions. How often do you open a recordset and loop through the records? Sound like the functionality of a cursor? Is it a coincidence that there are arguments to OpenRecordset methods (such as adOpenForwardOnly, adOpenKeyset) that map almost directly to arguments that are passed when creating T-SQL cursors. These API's create cursors when you use OpenRecordset. So basically from your statement you can conclude that one of the most common data operations performed against an MSSQL database from a client application is absolutely horrible in performance. I'm not buying it. Neither are the millions of applications and developers using ADO and ODBC recordsets with a SQL server database - I think somebody might have noticed.
Now since we know it's not cursors that are slow, perhaps it's just the database product itself? Nope, it's the fastest tested database in the world in several areas.
When I read your post I was a little surprised, when I've used cursors they've been extremely
efficient. What types of things were you doing, with how much data? Granted I'm not using millions of records, but I don't think cursors are appropriate for such large data sets.
In my test I'm running a SQL 7 on a 700mhz (or something close) P3 with 512k.
I open a local fast_forward cursor, select 5 fields (integer & 4 varchar(50)'s ) into variables,
loop through all of the records and print the integer at the end. Here are my result times:
1000 : Under 1 second
10000 : 1 second
201000 : 10 seconds
Maybe I'm missing something or I don't use cursors the way the rest of the industry does, but I can deal with those performance levels.
Slashdot Mirror
What are you talking aboot?
I believe the security in .NET is a sandbox system, but it's also flexible. Apparently there's a way for your applications to define custom actions and then users can grant or deny permission to perform that action. Seems like a pretty good idea compared to the sandbox being completely defined by the platform/language.
Your experience was completely different than mine. Several months ago I set up an account, even used it limited places on the net, and I've gotten maybe 5 spams total. Even the ones I did receive have been placed directly into the Junk Mail folder (browser) or Bulk Mail (Outlook Express). I'd say their anti-spam initiative has done pretty well, I watch friends with netscape mail fill up with over 60 spams a day.
That's really easy to say, a lot harder to do.
A lot of the applications I've written have been Access/VB front ends with Access/SQL backends. (Yea, I know what most of the slashdot community thinks about those development tools but that's a different argument...). I've seen more RAM on a server *drastically* improve performace, for example a process that takes 10-15 seconds become almost instant. These are custom apps, where the customer pays per hour about as much as it costs for like what, 256 megs of RAM (don't know current prices but it IS cheap). So if an app is performing slowly, you can either rewrite the logic, introducing new bugs, spending lots of hours coding, testing, building releases, etc., or sometimes you can pop some RAM in and the problem goes away. This isn't to say that all performance issues are handled by RAM, sometimes code just sucks, but this has been the solution on numerous products I've worked with.
there's sure to be .l33t and .H4X0r
And after we've convicted the Talibans, who give shelter to bin Laden, what next? There seems to be plenty of evidence pointing to bin Laden. Bush has already declared we will attack those who aid the terrorists. So we'll have to attack somehow, and a ground war sure won't be pretty.
What's your idea for retaliation then? US ground troops? This will certainly cause more innocent deaths on both sides.
I think we should bomb the hell out of Afghanistan, at least the main areas that the Talibastards inhabit, and turn it into a nice vacation resort for the civilized people of the world.
ADO, OLE DB, ODBC and DB-Library all expose the functionality of cursors through recordsets. From my experience recordset operations have to be one of the most common operations of database applicaions. How often do you open a recordset and loop through the records? Sound like the functionality of a cursor? Is it a coincidence that there are arguments to OpenRecordset methods (such as adOpenForwardOnly, adOpenKeyset) that map almost directly to arguments that are passed when creating T-SQL cursors. These API's create cursors when you use OpenRecordset. So basically from your statement you can conclude that one of the most common data operations performed against an MSSQL database from a client application is absolutely horrible in performance. I'm not buying it. Neither are the millions of applications and developers using ADO and ODBC recordsets with a SQL server database - I think somebody might have noticed.
Now since we know it's not cursors that are slow, perhaps it's just the database product itself? Nope, it's the fastest tested database in the world in several areas.
When I read your post I was a little surprised, when I've used cursors they've been extremely
efficient. What types of things were you doing, with how much data? Granted I'm not using millions of records, but I don't think cursors are appropriate for such large data sets.
In my test I'm running a SQL 7 on a 700mhz (or something close) P3 with 512k.
I open a local fast_forward cursor, select 5 fields (integer & 4 varchar(50)'s ) into variables,
loop through all of the records and print the integer at the end. Here are my result times:
1000 : Under 1 second
10000 : 1 second
201000 : 10 seconds
Maybe I'm missing something or I don't use cursors the way the rest of the industry does, but I can deal with those performance levels.
Maybe you're talking about a different implementation of looping through a rowset, but you can do this...
DECLARE csrName CURSOR FOR SELECT * FROM #table1
OPEN csrName
FETCH NEXT FROM csrName INTO @Field
WHILE @@FETCH_STATUS = 0
BEGIN
--do something
PRINT @Field
FETCH NEXT FROM csrName INTO @Field
END
DEALLOCATE csrName
I was originally looking at getting a high end Mac, but then I ran across this baby and saved myself a good $1500!
disclaimer: That's not my machine but if it was I wouldn't want anyone else claiming it - so props to the real owner