---------------------
Row  :  Y/N
---------------------
1           Y
2           N
3           Y
4           Y

Becomes

-------------------------------
Row  :  Y/N  :  String
-------------------------------
1           Y
2           N       YN
3           Y       YNY
4           Y       YNYY

and so on.

Any help would be much appreciated.

CREATE TABLE Foo (
  fookey INT NOT NULL PRIMARY KEY,
  y_n CHAR(1));

INSERT INTO Foo VALUES(1, 'Y');
INSERT INTO Foo VALUES(2, 'N');
INSERT INTO Foo VALUES(3, 'Y');
INSERT INTO Foo VALUES(4, 'Y');

SELECT A.fookey, A.y_n,
       (SELECT '' + B.y_n
        FROM Foo AS B
        WHERE B.fookey <= A.fookey
        ORDER BY B.fookey
        FOR XML PATH('')) AS yn_path
FROM Foo AS A;

/*

fookey      y_n  yn_path
----------- ---- ---------
1           Y    Y
2           N    YN
3           Y    YNY
4           Y    YNYY

*/

DROP TABLE Foo;

This ought to be in VIEW so that a change in the rows will cascade, if
you insist in throwing out First Formal Form.

Hardly horrible but certainly maintainable.

By narrowing your solutions into pure 100% ansi standard SQL you are just
costing your client money because has you have just stated, you will need to
not only consider writing SQL but also you will need further skills in
writing in a programming langauge say C for instance which is the only one
that is widely used and has a standard implementation. I've not even started
to mention the costs in terms of testing, releasing and supporting these
additional items your chosen solution would mandate.

What is the correct solution - well, in business the investment will have
been made in the product SQL Server so to get the maximum return on that
investment you aren't going to hire another programmer just because you want
to stay "portable" - and I use that term loosely because any professional
out there will tell you portability is not something that is really
achievable.

I bet people actually laugh at you once you've left the building; or more to
the point - do you actually do any real consulting in the Microsoft field?
Or is it all just as I expect adhoc training a couple of times a year?

--ROGGIE--

You narrow your solutions by writing in dialect; you increase their
scope, maintainability and robustness by sticking to Standards.
Having something that runs in only one release of one version of one
SQL is not a good thing.

But strong dialect code gives you job security.  Even better, write
your code in an unsupported version that only you know.

I have never worked anywhere that the whole system was in SQL; there
is always a front end language of some kind --C#, Cobol, Java, PHP,
etc.  The front end languages do their job far better than SQL.  I do
not want to screens with just a PRINT statement in T-SQL.