Dave Britten

I generally divide Casio's programmable calculators into two groups: the older models with Defm/array memories, and the newer ones that use list variables. The Defm models may be older, but they offer some interesting advantages over the newer list-based models.

These programs enable easily and accurately calculating TVM and amortization problems on old Casio calculators in about 350 bytes of code.

The Casio fx-6300g graphing calculator has a subtle bug that affects using certain comparison operators against array memories, which will effectively cause the two sides of the comparison operator to be swapped. Here's how to trigger the bug, and what you can do to avoid it.

Despite being released about 4 years after the TI-82, the TI-86 does not include median-median regression, which can be a useful method of linear regression for data with extreme outliers. Fortunately it's a simple enough algorithm to implement in a small program.

Here's a small TI-86 program for twiddling Linux/UNIX permission bits and seeing both the symbolic and numeric results. The simple ones (750, 640, 755, etc.) are easy enough to do in one's head, but it can start to get a bit messy when setuid, setgid, and sticky get involved.

I bought an old Casio fx-6300g graphing calculator from ebay (it's so tiny!), and couldn't find many programs written for it. Who would imagine that the internet wouldn't be awash in programs for an obscure, low-end calculator from 27 years ago? So, I wrote a few: prime factors, binomial probability, and negative binomial probability.

Generally, I don't trade in warez on this site, but for software that's pretty much abandoned, and the original company having vanished, I'm willing to make an exception.

Know what would be awesome? If, instead of the usual cursor-and-local-variables ceremony, T-SQL would let you just do something like this:

FOREACH logrow IN (SELECT logdate, logtime, event_type, user_name, result FROM LogData) FAST_FORWARD
BEGIN
    INSERT INTO failure_log SELECT logrow.logdate, logrow.logtime, logrow.user_name WHERE logrow.result != 'SUCCESS'

    EXEC do_something_with_log_data @date = logrow.date, @time = logrow.time, @result = logrow.result
END

But alas, it does not. I'll have to continue to put up with a bunch of DECLAREs and 'FETCH NEXT INTO...'

Personal Information Management The Old Fashioned Way

I have crohn's disease. It's not terminal or anything like that, but that's the most succinct way of conveying that I see a lot of doctors, and take a lot of medication. For a few years, I've hemmed and hawed over how to keep all of my records someplace organized. I've spent hours looking at database apps for my iPhone and iPad, I've considered using some version of MS Access (or a similar tool) to build my own, and I've looked at various hosted "cloud" solutions ...

These aren't particularly sophisticated, but we had a sudden need to do some reporting based on a vendor's fiscal year, and this should get the job done. Use freely (at your own risk).

CREATE FUNCTION dbo.first_day_of_fiscal_year(@date datetime, @fiscal_year_start_month int, @fiscal_year_start_day int)
RETURNS date
AS
BEGIN
    DECLARE @fy_start datetime = CAST(DATETIMEFROMPARTS(YEAR(@date), @fiscal_year_start_month, @fiscal_year_start_day, 0, 0, 0, 0) AS date)
    IF @fy_start > @date
        SET @fy_start = DATEADD(year, -1, @fy_start)
    RETURN @fy_start
END

GO

CREATE FUNCTION dbo.last_day_of_fiscal_year(@date datetime, @fiscal_year_start_month int, @fiscal_year_start_day int)
RETURNS date
AS
BEGIN
    RETURN DATEADD(dy, -1, DATEADD(year, 1, dbo.first_day_of_fiscal_year ...

We've got a fairly large Reporting Services installation in our organization. We've been using it for about eight or nine years, so we've accumulated several hundred reports in that time. Without going into undue detail about the server organization, we have all the deployed reports in a directory structure underneath "/Base Reports" that makes it easy for developers to see where (i.e. project, solution) a given report came from. All of these reports are then presented in separate directory structures where all the security is defined, e.g. a directory for the sales team, purchasing team ...

Fun things to do with a ~$35 home server

I find myself often needing to have some kind of audit trail for a table in SQL Server, i.e. some way to look at before-and-after data, who changed it, when, etc. I've set up enough of these manually that they were becoming formulaic, so I figured why not put together a procedure that creates them for me and writes the necessary trigger?

Attached is the version I'm currently using. The syntax is pretty simple. Here's an example, a real one that I just set up:

EXEC sp_CreateDataAudit
        'dbo',
        'IV00200',
        'audit',
        'IV00200',
        NULL,
        'tr_IV00200_Audit',
        'SERLNMBR,UNITCOST,RCTSEQNM ...

If you're a DBA, especially one that has to deal with an ERP system that has no concept of silly things like "transactions", then you've probably got a collection of scripts to update and fix data as necessary.

And you probably (hopefully) run a SELECT before actually changing data, to visually confirm what will happen. You might do this by either having both a SELECT and UPDATE query in the script, or by commenting out the SELECT or UPDATE portions of the script as needed, or some other technique.

Here's an approach I've used for a ...

Triggers are an indispensible feature of SQL Server. Essentially stored procedures that are invoked automatically, a trigger can be used to perform logging, data validation and cleaning, synchronization, and notification, and implement referential integrity constraints that are too complicated for foreign keys, among, no doubt, plenty of other things.

But alas, any seasoned SQL Server DBA is probably familiar with the minefield of performance-related and other issues that can very easily stem from misuse or overuse of triggers. I've frequently been victim to (and perpetrator of) such issues myself.

So what does it take to write a good, well-behaved ...