Follow Slashdot stories on Twitter


Forgot your password?
Compare cell phone plans using Wirefly's innovative plan comparison tool ×

Comment Re:Sadly needed (Score 2) 119

If Microsoft bothered to distinguish between 'opening' a file and 'running' a program - and double-click would only open, not run - then at least part of the problem would be fixed. But since the earliest days of Windows, the same verb 'Open' has been used for both operations. We can't blame users if they have been trained that double-clicking is the standard way to open a file (surely a safe operation in any sanely written system) but then the OS turns it into the much more dangerous operation of running a program.

Comment Re:I'm somewhat (Score 1) 105

Many RDBMSes allow more than one statement per batch - so you can execute two or more statements in a single round trip. For example you could do 'if exists (blah) ...', assuming your dialect of SQL supports it, in just one round trip, or even separate 'insert where not exists... update...' or whatever technique you want to use. (I am not saying that these techniques are a foolproof alternative to merge or upsert, they are not, but that is for another discussion.) If you have multiple rows, you can still prepare a statement handle and handle them in the same number of round trips it would require for a single insert, or at most one extra round trip for the whole batch. Essentially - the checking for an existing row, even without a merge / update builtin, can usually be done in SQL rather than clunkily by the client app.

Comment Re:I'm curious (Score 1) 105

There is no exact equivalent in traditional SQL. As others have pointed out, you can check exists and then insert, but that introduces a race condition; wrapping it in an explicit transaction might help depending on the locking model, but might still introduce failures that have to be introduced by client code.

That said, if you can make some assumptions about what else is writing to the table then you can get fairly close. One technique I often use is like this:

-- Insert the row if none with the same PK exists.
-- As a single SQL statement, this executes atomically
-- in all but the most braindead DBMSes.
insert into mytable (keycol, datacol)
select 1, 'a'
where not exists (
select 0
from mytable
where keycol = 1

-- OK, now there is definitely a row there with keycol=1.
-- Update the row which exists.
-- This is redundant work if we just inserted it above, but do it anyway.
update mytable
set datacol = 'a'
where keycol = 1

This is clearly not safe in general. If there are others accessing the table and doing general delete, or test-and-set, it can lose data. However, if you know that code like the above is the only code accessing the table, or if you restrict it to the above plus simple inserts, then you have a safe way to insert-or-update a row that doesn't involve holding locks for a period of time and doesn't require an explicit transaction.

Comment Re: Use a larger monitor. (Score 1) 197

It depends on the monitor. Some will let you run at a resolution of exactly half and scale crisply, so that each pixel from the computer becomes a neat square of four pixels on the monitor. Sadly there are too many monitors which generate a blurry mess even when doing an exact integer scaling like this. (From my limited experience older monitors are better than newer in this respect.) Scaling in the video hardware is the same. It's from a misapplied idea that fancy scaling like bicubic is superior to the naive nearest-neighbour. That is true for photographs, but not for input images which are intended to have exact pixel boundaries. My first resort would be to set a font scaling of 200% in the operating system. If running Windows it may help to turn off Aero, so that (as above) you get clean pixel scaling and not blurring.

Slashdot Top Deals

How many surrealists does it take to screw in a lightbulb? One to hold the giraffe and one to fill the bathtub with brightly colored power tools.