If I have a table with an INTEGER key - can I use negative key values?

- Oystein -

Oystein ..

You can, but you might get some unexpected side issues. You obviously won't be able to use the standard %SK% logic to assign keys. Key sorting and reports will have to take the collating sequence into account. You might also have difficulty if you wanted to use multi-part keys, although it might be ok if the negative integer was the 2'nd part (or higher).

I'm intersted in why you'd do this, though. Probably some arcane Nordic thing that eludes me.

Don M.

Don,

I have this new program that reads rows from a table with integer keys in ascending order and converts the data to a different format in other tables. I needed to test the program. I had some real data, but wanted to include some challenging data of my own, to make sure some special cases were covered. I wanted my own data to be processed first. I therefore thought of assigning my own data rows lower keys than the existing ones, but then the new keys had to be negative.

I came up with a different solution. I asked anyway.

But since you took the bait:

- Are you sure %SK% would not work?

- What's that with the collating sequence?

Aren't negative integers valid INTEGER keys?

- Oystein -

Oystein ..

]] came up with a different solution. I asked anyway.

]]

]]But since you took the bait:

]]- Are you sure %SK% would not work?

]]- What's that with the collating sequence?

]]Aren't negative integers valid INTEGER keys?

I haven't tested it in OI, but I did in AREV. I manually initialized the starting SK value to -1 and then had it assigned in a form. Sure enough, it went to 0 (e.g., the routine increments the value by one).

So, my assumption is that it works for positive integers and not negative ones.

Well, if the value is defined as INTEGER type, then a B-Tree on the key will return values collated properly (e.g., the highest negative number at the top and then descending through 0 to positive integers. If that is what you want, then OK, but if the keys grow to larger NEGATIVE integers as they are assigned, then the most recent one will be at the top. If this were a series of transaction numbers or suchlike, then they will be out of sequence with respect to the entry order.

Negative numbers are valid integer keys (obviously). The only funny issue is with zero-filled integers (which get the leading zero's stripped).

OK, I bit you your line .. what's next? Have a good one .. Thanksgiving here, but who knows what there ..

Don M.

Don,

]]But since you took the bait: ]]- Are you sure %SK% would not work? ]]- What's that with the collating sequence? ]]Aren't negative integers valid INTEGER keys? I haven't tested it in OI, but I did in AREV. I manually initialized the starting SK value to -1 and then had it assigned in a form. Sure enough, it went to 0 (e.g., the routine increments the value by one). So, my assumption is that it works for positive integers and not negative ones.

You unmathematical you. I'm not expecting a %SK-DSND%. I do expect it to go from -1 to 0 because 0=-1 + 1. Except I'd start a bit lower to avoid reaching 0 and positive values for a while.

OK, I bit you your line .. what's next?

Haven't you guessed yet? - Can I have INTEGER keys plus and minus infinity?

Have a good one .. Thanksgiving here, but who knows what there ..

My own birthday. Beats Thanksgiving.

- Oystein -

Oystein ..

Of course, you could be a VERY clever soul and continuously increment the key value until the whole thing comes to a screeching halt. Years ago, I wrote an "infinitely recursive" Bill-Of-Materials processor that could do that .. e.g., put a part number in the chain that kept calling itself. It was fun to watch the levels keep expanding until the infamous 64K barrier was exceeded at each level. Ugly, indeed, but ..

I assume you've solved your own issue already. Have a happy birthday .. you ARE fun to have around.

Don M.

Don,

The birthday's not yet. I just told you early so you have time to send presents.

- Oystein -

View this thread on the forum...