Curious Error

04/24/2013 13:53 TeddyBear94#1
Hey Guys i have noticed a curious error in my loggs and tbh i have no clue how they appeared nor how i should fix them.
I already executed the usp_save_char_info_e new but yet it doesnt made any difference.
I would be rly glad if anyone got a clue or a hint for that prob :o






04/24/2013 16:19 castor4878#2
- in
Quote:
call usp_Save_Char_Info_E(153,70,0,5,10,19,9,7,8,12,606 4,474,1406,43,250,21000,200000,'1141.413208','16.3 17999','1597.816772', 0,200,0,0,0, 1000000,0,0,0, 0,0)
the Hp parameter is "606 4" instead of 6064; is it a typo due to log process or copy/paste in this post?

- usp_Save_Char_Info_E, the "classical" one does not perform any subquery, it only contains a where clause with the @CharID argument.
did u change that SP ? can u post the one u are using?
04/24/2013 19:51 TeddyBear94#3
thats the one i use and no i never changed that one ö.ö
the problem appeared out of nowhere D:
04/24/2013 21:27 x-DoeSn'TxMaTTeR-x#4
Source: [Only registered and activated users can see links. Click Here To Register...]

Charlie___XXX25 Points:
0
set @assignedID = (select ID from RecordTable where DateSubmitted = @dateSubmitted)



my guess is that you get that error because you insert more than one record with the same datesubmitted value.

Reply Quote
Tuesday, June 26, 2007 3:02 PM

SomeDeveloperPerson130 Points


0
Charlie___XXX wrote:
set @assignedID = (select ID from RecordTable where DateSubmitted = @dateSubmitted)

my guess is that you get that error because you insert more than one record with the same datesubmitted value.




That's not possible. The error occurs even when the RecordTable is empty.
Reply Quote
Tuesday, June 26, 2007 3:10 PM

SomeDeveloperPerson130 Points


1
SomeDeveloperPerson wrote:
Charlie___XXX wrote:
set @assignedID = (select ID from RecordTable where DateSubmitted = @dateSubmitted)

my guess is that you get that error because you insert more than one record with the same datesubmitted value.




That's not possible. The error occurs even when the RecordTable is empty.


Charlie... you're actually correct. I modified the line to:
Code Snippet
set @assignedID = (select MAX(ID) from RecordTable where DateSubmitted = @dateSubmitted)



And it works with no problems now. Apparently the code is executing faster than expected so that several records are being written in under a millisecond.
04/24/2013 21:48 castor4878#5
your example is perfect DSTM

set @assignedID = (select ID from RecordTable where DateSubmitted = @dateSubmitted)

is indeed inherently invalid.

but the original usp_Save_Char_Info_E and the version posted by Teddy doesn't contain such statement.

I also assume that the call to the unknown "sp_Update_Char sPVPData_E" proc is actually in a comment (the log does not indicate that error occured in that SP neither).

The error has so far no explanation with the given information.

Teddy, the calls logged in the out file can be executed (as any valid sql stmt), so try to execute one of the

call usp_Save_Char_Info_E(153,70,0,5,10,19,9,7,8,12,606 4,474,1406,43,250,21000,200000,'1141.413208','16.3 17999','1597.816772', 0,200,0,0,0, 1000000,0,0,0, 0,0)

in a query window. add all useful output in the SP, eg:

PRINT 'step N' + @CharID

-------------------------------------------------------------------------

after 5th reading ... there is non consistant definition.

the PS_BDAGENT logs:

usp_Save_Char_Info_E(153,70, 0,5, 10,19,9,7,8,12, 6064,474,1406, 43,250, 21000,200000, 1141.413208,16.317999,1597.816772, 0,200,0,0,0, 1000000,0,0,0)

so it manages posX, posY, posZ as reals and it doesn't transmit the @KillLevel and @DeadLevel parameters ... this is (except enormous mistake) not possible, these last 2 params are mandatory.

meantime, the SP you provided does define:

[...] Proc [usp_Save_Char_Info_E]

@CharID int, @Level int, @StatPoint smallint, @SkillPoint smallint,
@Str smallint, @Dex smallint, @Rec smallint, @Int smallint, @Wis smallint, @Luc smallint,
@Hp smallint, @Mp smallint, @Sp smallint,
@Map smallint, @Dir smallint, @Exp int, @Money int,
@Posx real, @Posy real, @Posz real,
@Hg int, @Vg int, @Cg int, @Og int, @Ig int,
@K1 int = null, @K2 int = null, @K3 int = null, @K4 int = null,
@KillLevel tinyint, @DeadLevel tinyint

where posX|Y|Z are indeed real, so the call would be correct, expect the 2 missing last params.

OOH, the second log gives:

2013-04-23 11:14:15 err=-1, [Microsoft][ODBC SQL Server Driver][SQL Server]Subquery returned more than 1 value. This is not permitted when the subquery follows =, !=, <, <= , >, >= or when the subquery is used as an expression., SQL STATE: 21000, NATIVE ERROR: 512 (0x200)

2013-04-23 11:14:15 ::SaveCharacter 153 Tedde ret=1, qerr=-1, {
?=call usp_Save_Char_Info_E(153,70,0,5,10,19,9,7,8,12,606 4,474,1406,43,250,21000,200000,'1141.413208','16.3 17999','1597.816772', 0,200,0,0,0, 1000000,0,0,0, 0,0)}

where one reads:

usp_Save_Char_Info_E(153,70,0,5,10,19,9,7,8,12, 6064, 474,1406, 43,250,21000,200000,
'1141.413208','16.3 17999','1597.816772',
0,200,0,0,0,
1000000,0,0,0,
0,0)

the 3 coords are transmitted as string (they are single-quoted) (and the Kill / Dead levels are provided)

this point shall be fixed. your SP excepts real or string but not both, and function overloading is AFAIK not supported by SQL (we can not have both with 2 prototypes).

my own SP is:

where coords are given as string and the final client (the PS_Login.exe and PS_Game.exe) shall comply with this declaration and thus provide a pointer to string, not a real8.

may be the ODBC middleware manages the coercion of data.
but may be this real / string mistake is the cause of your error, the SP failed to be called due to invalid parameter and reported errors are wrong (exact cause is lost bacuse no actual call is made).

you should check this assumption with the SP above.
04/27/2013 06:55 TeddyBear94#6
error got fixed
i noticed that i deleated all my chars and accounts and made new accounts which was the problem as the old items from that accounts caused these problems. i moved the new accounts to UserUID 50+ and now it works all fine.
thats for the input the thread can be closed ;)
04/28/2013 03:04 JohnHeatz#7
#Closed as requested