以下是SQL Server存储过程的摘录:
ALTER PROCEDURE [dbo].[spAddLogin]
@gameid INT,
@serverid INT,
@memberid VARCHAR(15)
AS
BEGIN
SET NOCOUNT ON;
DECLARE @lastLoginTime datetime
DECLARE @lastLoginDate datetime
DECLARE @isRelogin bit
SELECT
@lastLoginDate = LoginDate,
@lastLoginTime = LoginTime
FROM
Logins
WHERE
LoginDate = (SELECT MAX(LoginDate)
FROM Logins
WHERE MemberID = @memberid AND GameID = @gameid);
当我运行此存储过程并输出时@lastLoginDate,@lastLoginTime我得到的是null。
但是,经过大量的挫折和测试,我发现当我对输入参数的值进行硬编码时@memberid,@gameid它可以正常工作。实际上,如果我硬编码@memberid并保留@gameid参数化设置,它仍然可以正常工作。
它与以下事实有关@memberid:varchar在下面的摘录中它作为null出现,而我可以将@gameid参数保留在其中,因为那是一个int。它是否正确?我究竟做错了什么?
再次,如果我运行完全相同的代码,除了硬代码“ 1234”而不是@memberID参数
SELECT @lastLoginDate = LoginDate, @lastLoginTime = LoginTime
FROM Logins
WHERE LoginDate = (SELECT MAX(LoginDate)
FROM Logins
WHERE MemberID = '1975A' AND GameID = @gameid);
版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。
从你的描述来看,问题似乎出在参数@memberid
的类型和值传递上。你提到当直接硬编码@memberid
的值时,存储过程能够正确执行并返回预期结果,但使用变量时却得到NULL。这通常意味着参数传递给存储过程时可能存在不匹配或数据类型问题。
考虑到@memberid
定义为VARCHAR(15)
,这里有几个可能的问题及解决方案:
数据类型不匹配:确保调用存储过程时传入的@memberid
值与定义的数据类型相匹配。如果你是从其他程序或脚本调用此存储过程,请检查是否正确地将字符串值作为参数传递,而不是其他类型(如整数)。
空值或空字符串:如果@memberid
在调用时是空值(NULL)或空字符串(''),并且数据库中的查询逻辑依赖于它不为空来匹配记录,那么可能会返回NULL。你可以考虑在存储过程开始时加入检查逻辑,以确保@memberid
不是NULL或空字符串。
字符大小写或前导/尾随空格:如果MemberID
字段对大小写敏感,或者存在前导/尾随空格,即使看起来相同的值也可能导致不匹配。可以考虑在比较时使用UPPER()
或TRIM()
函数来标准化值,例如:
WHERE UPPER(TRIM(MemberID)) = UPPER(TRIM(@memberid))
字符编码问题:虽然较为少见,但如果@memberid
包含特殊字符且编码方式与数据库中数据的编码方式不一致,也可能导致匹配失败。
为了调试,你可以在存储过程开始时添加一些打印语句来检查@memberid
的实际值和数据类型,比如使用PRINT
语句:
PRINT 'memberid: ' + @memberid;
同时,也可以直接在存储过程中检查Logins
表中是否存在匹配的记录,通过添加一个临时的SELECT语句来验证查询条件是否按预期工作:
SELECT COUNT(*)
FROM Logins
WHERE MemberID = @memberid AND GameID = @gameid;
这样可以帮助你确定问题是否确实出在参数传递上,还是其他地方。