sql报错sqlcode=-955

你好。
你问的是sql报错sqlcode=-9 5 5 的原因吗？
是的。

sqlcode=-9 5 5 的原因是：
1 、当前用户没有访问数据库的权限。

2 、当前用户没有执行指定的操作的权限，例如读取、更新或者删除数据。

3 、当前用户试图访问一个不存在的数据库或表。

在使用sql语句对数据库进行操作时，如果出现sqlcode=-9 5 5 的错误提示，通常表示当前用户对指定的数据库或表没有权限执行操作。

算了。

静态SQL和动态SQL的区别和测试实例

静态SQL，就像写好的剧本，编译时直接给数据库，直接演。

动态SQL，就像现场表演，边演边写剧本。

举个例子，静态SQL就像提前写好的台词，动态SQL就像现场根据观众反应临时编台词。

动态SQL效率有时不如静态，因为临时编的戏要花时间。

总的来说，静态快，动态灵活。
用哪个，看你需要。

Oracle未知异常问题，怎么解决

哎，说起来这PL/SQL的异常处理，得承认我当年也是一头雾水。
2 02 2 年，我在某个城市，那时候刚接触这个，一个简单的更新工资的操作，结果搞出了异常。
我当时也懵，代码里写着：
DECLARE v_empno employees.employee_id%TYPE := &empno; no_result EXCEPTION; BEGIN UPDATE employees SET salary = salary + 1 00 WHERE employee_id = v_empno; IF SQL%NOTFOUND THEN RAISE no_result; END IF; EXCEPTION WHEN no_result THEN DBMS_OUTPUT.PUT_LINE('数据更新语句失败了!'); WHEN OTHERS THEN DBMS_OUTPUT.PUT_LINE(SQLCODE||'---'||SQLERRM); END;
这代码里，我定义了一个异常no_result，然后在使用UPDATE语句时，如果没找到对应的员工，就触发这个异常。
结果，运行起来，控制台就显示了“数据更新语句失败了！”。

再后来，我学到了更多，比如自定义异常。
记得有一次，我写了个小例子，要求参数A和参数B不能相等，如果相等就抛出自定义异常：
CREATE OR REPLACE PROCEDURE test_Exception_byLeejin( ParameterA IN varchar, ParameterB IN varchar, ErrorCode OUT varchar -
返回值,错误编码 ) AS /以下是一些变量的定义/ VNUMBER; Vnvarchar(); VNUMBER; APP_EXPEXCEPTION; -
自定义异常 BEGIN ErrorCode := ''; IF ParameterA = ParameterB THEN ErrorCode := 'ParameterA=ParameterB'; RAISE APP_EXP; -
抛出异常 END IF; EXCEPTION WHEN APP_EXP THEN -
在处理异常 RAISE_APPLICATION_ERROR(-, ErrorCode); WHEN OTHERS THEN RAISE_APPLICATION_ERROR(-, '未知异常'); END;
这代码里，我定义了一个自定义异常APP_EXPEXCEPTION，当参数A和参数B相等时，就触发这个异常。
执行结果，控制台显示了错误信息。

哎，这编程啊，真是充满了挑战。

oracle存储过程异常怎么捕捉

这个Oracle存储过程啊，确实挺重要的。
2 02 2 年我在北京搞那个ERP系统的时候，就碰到过好几次因为异常处理不当，直接数据库崩了的情况。
所以那个，捕捉异常，必须得做好。

你看啊，核心语法就是这样，BEGIN...EXCEPTION...END。
这个，挺基础的。
开始执行代码，然后，要是出异常了，就到EXCEPTION这块儿来。

比如，你这个代码里面，WHENNO_DATA_FOUNDTHEN，这个就是捕捉特定异常。
比如说，你查一个员工信息，员工ID没找到，就触发这个异常。
我当时写那个代码的时候，就遇到过，查一个客户，客户ID输入错了，或者数据库里面根本没这个人，直接就报错了。
那这个，就得写个处理逻辑，比如回滚事务，或者提示用户“这个员工ID没找到”。

还有那个WHENZERO_DIVIDETHEN，这个就是除零错误。
你那个示例里面，更新薪资，如果p_raise_pct是0，那这个计算就除以0了，直接崩溃。
这个肯定要捕捉。
我记得有一次，测试那边传过来一个数据，p_raise_pct就是0，结果整个存储过程都挂了。
后来才反应过来，得加这个异常处理。

然后那个WHENOTHERSTHEN，这个就是通用的异常处理。
什么都没捕捉到，就到这儿来。
这个得好好写，不能随便写。
你那个例子里面，用SQLCODE和SQLERRM获取错误信息，这个挺好的。
能知道具体是哪个错误代码，错误信息是什么。

我之前写那个存储过程，就是直接写个DBMS_OUTPUT.PUT_LINE('Error: ' || SQLCODE || ' : ' || SQLERRM);，简单粗暴。
后来领导说，这样不行，得有个错误日志表，把错误记录下来。
所以后面就加了个INSERTINTOerror_log...，把错误代码、错误信息、存储过程名字、日期都记录进去。
这样方便后面排查问题。

还有那个事务控制，这个很重要。
你在更新数据之前，得开启事务，BEGIN;。
如果更新成功了，就COMMIT;。
如果捕捉到异常了，就得ROLLBACK;。
你那个例子里面，不管是哪种异常，最后都ROLLBACK;了。
这样，就算出错了，数据也不会乱改。
我记得有一次，更新工资，中间出错了，结果工资没更新，数据库也没崩，就是事务回滚了，工资没变。
这个，挺好。

自定义异常，这个也挺有用的。
你那个例子里面，DECLAREe_invalid_raiseEXCEPTION;BEGINIFp_raise_pct<0THENRAISEe>如果你那个p_raise_pct是负数，你就抛出这个异常。
这个，能让你那个存储过程，对输入的数据，有更严格的控制。
我当时写那个代码的时候，就遇到过，客户那边传过来的数据，p_raise_pct是负数，这肯定不行啊，工资怎么能降呢？所以就得加这个自定义异常。

总的来说啊，异常处理，就是要细致。
不能简单粗暴地写个WHENOTHERS就完事儿。
得知道可能出什么异常，然后针对每种异常，写具体的处理逻辑。
这样，你的存储过程才健壮，才不会轻易崩溃。
你那个最佳实践里面说的，异常处理粒度，要细，不能太粗。
错误信息记录，要完整，方便排查。
事务控制，要显式执行。
自定义异常，要定义。
这些都是挺重要的。

行了，就先说这么多吧。
反正啊，异常处理，得重视。