That's quite clear as far as it goes, but it leaves some questions open. You seem to think that it's something that can be written as a single SQL statement, but as I read it you have secified a constrained maximisation problem which may not be possible to express efficiently in such a way.

For example, if I have

datakey landline

1 100

1 200

1 300

2 200

2 300

2 100

3 300

3 100

3 200

in the data you presumably want the uniquelandline count to be 3 because it is possible to find 3 (datakey, landline) combinations no two of which have the same langline or the same datakey. And presumably you also want the count to be 3 is what I have is

1 100

1 200

1 300

2 100

2 200

2 300

3 100

because it is still possible to choose 3 combinations which are distinct in both fields: (1,300), (2,200),and (1,300).

But of course if I pick (1,100) and (2,200) there is no landline value I can pick to go wioth datakey 3, because its only lanline has already been counted with datakey 1, so to get the right answer I have to maximise the number of combinations by not choosing (1,100) in this case. And also by not choosing (2,100) in this case.

If that is the requirement (with a simlar requirement for each of the other fields) then none of the code suggested so far comes anywhere near doing what you require, because what you have is a constrained maximisation problem which probably needs trial and backtrack to resolve it, and the code so far makes no attempt at all at doing such maximisation.

If the answer 2 (instead of 3) would be acceptable in the second case, things may be simpler - but you need to find a way of expressing clearly what the requirement is before we can be sure that it is simpler. For example if your count were defined as the smallest number such that a set with that number of combinations satisfying the distinctness rule can be found from your table is not a proper subset of any set obeying the distinctness rule than can be taken from the table you have an equally nasty constrained minimisation (then, of course, 2 would be the only acceptable answer in the second case). If both 2 and 3 are acceptable, maybe the answer can be any number which is the size of some set of comginations which satisfies the uniqueness rule and is not a proper subset of another such set; in that case you genuinely can have simpler code, but you may find that if you run the query twice on the same data you can get two different answers if for example an index has been defragmented between the two runs, or if an extra CPU has been added to the server.