Distinguishing between 0 and null

[Undertowe]

Quick question. Let's suppose I was using the APS function GetPersistentInt() to retrieve a boolean value from the DB. If the value isn't found the function returns 0. If the value is found and is 0 the function returns 0. How the heck should I distinguish between the two?

I'm actually writing my own function for this, but have run into the same problem. I thought about returning something improbable like -666 if the value wasn't found, but is there a better way?

Although, the more I think about it, maybe I don't need to distinguish between the two. I might get along just fine assuming that a return value of 0 means FALSE, whether it resulted from an actual value of 0 or a missing value. Still, it makes me a little uneasy not being able to determine which case it is.

Anybody else have this problem? How did you deal with it?

Thanks!

[Undertowe]

Here's another question.

Consider the following code from the APS function GetPersistentString():

[NoMercy]

Mabie it does, mabie it always will, but unless your campaigning for ultimate efficiency then I'd like to stick with the one which is obvious in it's function and resistant to changes in the underlying functions.

[Papillon]

Undertowe, the call to SQLFirstRow is necessary, and thus there is nothing left to optimize (the test for equality does not really count).

"If the value isn't found the function returns 0. If the value is found and is 0 the function returns 0."

This exactly emulates GetLocalInt's behaviour. If you want something else, you will need to check the return value of SQLFetch and only use the value of SQLGetData() when it returns SQL_SUCCESS, otherwise the variable does not exist.
_________________
Papillon

[Undertowe]

Thanks for the responses.

Papillon,

I just realized I made a mistake in my second code block. It should have read:

[Papillon]

I guess it is hard to give a generally acceptable approach to this problem. In programming languages like C, we have a NULL pointer, and in SQL, we have a NULL column value. In NWscript, we do not have something like this, so we have to stick with a convention of return 0 or FALSE for both cases.

If that does not work for you, these are your options:

1) Rethink your scripts and data retrieval. Honestly, all of the code of Avlis can do without running into this problem (and it IS huge, believe me).

2) Return the minimum negative value that an integer can hold in nwscript, which would be ... (looking up in nwnlexicon.com...) -2,147,483,648. I guess that value is somewhat unlikely to exist by happenstance.

3) Do not use a function, but query the database directly when you need a value. Use the return value of SQLFetch to decide if the variables exists or not.
_________________
Papillon

[Undertowe]