SQLEncodeSpecialCharacter Truncates at 127?

[seed]

When I run a string through the encode special characters function it gets truncated to 127 characters. Is this supposed to be?

[Grumalg]

At the top of the nwnx_sql include file you'll see a constant string smallColSpacer declared. The number of periods in this declaration sets the memory size reserved for passing data. The stock size of this string is where your truncation is comming from.

--- Grumalg ---

[seed]

so would this fix the issue? or at least allow me to encode 512 byte strings? (that should be enough length)

[FunkySwerve]

I've always wondered, why not set it larger still? Iirc, in nwnx2 its 8x128, would there be any adverse effects to increasing that more? I ask because I'm intending to hook the abilty to return SELECT statements into SIMTools, and am unsure whether the reserved space will be suffiecient, or even if it is an obstacle to that. It certainly seems like I've retrieved much more data from that on selects before.
Funky

[Gryphyn]

[seed]

so then the most efficent way to modify this code would be to reserve just enough 128 byte blocks to fit the data:

[Gryphyn]

[Grumalg]

Simplest way is to just enlarge the smallColSpacer string constant by adding period chars to raise it's total length. While you could build a longer string by looping concatenating it's size that will be slower than just useing the larger constant directly.

Looping doing SetLocalString doesn't help, because they don't add. The size is set by whatever the last SetLocalString() put in it. If you do want to loop concatenating the constant size, concatenate it in a string variable and then use that to SetLocalString with *once*.

Stock it's 128 chars useing period as a filler char. If you copied and pasted the period contents between the quotes, you'd double it to 256 char for example. You see truncation after 127 because of the terminating null which takes up the 128 char spot.

--- Grumalg ---

[dirt]

[seed]

dirt - use the SQLGetDataText for long columns:

// Return value of column iCol in the current row of result set sResultSetName
// Maximum column size: 128 characters
// Faster than SQLGetDataText()
string SQLGetData(int iCol);

// Return value of column iCol in the current row of result set sResultSetName
// Maximum column size: 1024 characters
// Somewhat slower than SQLGetData()
string SQLGetDataText(int iCol);

Grumalg - the code posted was looping and concatting a string *once* thanks for the replies

[Grumalg]

@dirt

The 'dot' string set in the loval var reserves a block of memory for nwnx to put returning data. Data returned gets truncated if it's bigger than the space reserved to prevent overwriting things that could be in memory past the reserved size. The max size of returned data is always one less than the 'dot' string length because of the null termination on the returned data.

@seed

My bad, I had only glanced at the code and responded under the impression it was looping around the SetLocalString. I had also forgotten about the SQLGetDataText function, as I haven't needed anything that large to date. Gimme 50 lashes with a wet noodle


In the demo module sticky thread you'll find some discussion about what the stock 'dot' string length should be. It looks like it's going to change from 128 to 256 as that will support everything one could use except large varchar, text, and blob fields. Thus it would avoid some of the truncation issue for new users.

--- Grumalg ---

[FunkySwerve]

I'm still not understanding how this memory reserve works - I'm fairly certain that I am exceeding it by far. Take the following for example:

[dirt]

[Via Con Diablos]

Funky:
The issue appears to be with the SQLEncodeSpecialCharacters, at least from what I'm reading in the thread.
All you are ever passing to it is the player's name, and ID, which I both imagine are smaller than that size.

The SQLExecDirect probably doesn't have the same character limitation.