技术标签： Oracle禁止用户delete
Oracle数据库用户无法删除的处理案例
删除用户提示信息
SQL> drop user jzfp cascade;
drop user jzfp cascade
*
ERROR at line 1:
ORA-00604: error occurred at recursive SQL
level 2
ORA-01422: exact fetch returns more than
requested number of rows
从错误提示信息可以看到，是sql递归出现多值条件或者重写sql语句。是由于执行一条SQL语句到导致，因此我们可以跟踪一下这个SQL语句的执行过程，希望可以得到一些蛛丝马迹。
以下是跟踪过程：
SQL> alter session set sql_trace=true;
Session altered.
SQL> alter session set events'10046
trace name context forever,level 4';
Session altered.
SQL> drop user jzfp cascade;
drop user jzfp cascade
*
ERROR at line 1:
ORA-00604: error occurred at recursive SQL
level 2
ORA-01422: exact fetch returns more than
requested number of rows
SQL> alter session set sql_trace-false;
alter session set sql_trace-false
*
ERROR at line 1:
ORA-00922: missing or invalid option
SQL> alter session set sql_trace=false;
Session altered.
跟踪文件文件目录：
/u01/app/oracle/diag/rdbms/jzfpysdb/jzfpysdb1/trace/jzfpysdb1_ora_25323.trc
这个目录可以根据user_dump_dest参数确定。
查看跟踪产生的trace文件发现在删除过程中有如下信息，注意表黑的语句：
=====================
PARSING IN CURSOR #140007753306960 len=61
dep=1 uid=0 oct=12 lid=0 tim=1471928680661235 hv=3312064677 ad='7f56186f5838'
sqlid='4d8b5vg2qn655'
drop table
"JZFP"."AH02_2014" cascade constraints purge force
END OF STMT
PARSE
#140007753306960:c=0,e=162,p=0,cr=0,cu=0,mis=1,r=0,dep=1,og=4,plh=0,tim=1471928680661235
PARSE
#140007751881456:c=0,e=15,p=0,cr=0,cu=0,mis=0,r=0,dep=2,og=4,plh=0,tim=1471928680661387
BINDS #140007748108528:
Bind#0
oacdty=01 mxl=32(04) mxlc=00 mal=00 scl=00 pre=00
oacflg=03 fl2=1206001 frm=01 csi=852 siz=32 off=0
kxsbbbfp=7f561818c1f0 bln=32 avl=04
flg=05
value="JZFP"
Bind#1
oacdty=01 mxl=32(09) mxlc=00 mal=00 scl=00 pre=00
oacflg=13 fl2=206001 frm=01 csi=852 siz=32 off=0
kxsbbbfp=7f56184df238 bln=32 avl=09
flg=09
value="AH02_2014"
Bind#2
oacdty=01 mxl=32(30) mxlc=00 mal=00 scl=00 pre=00
oacflg=13 fl2=206001 frm=01 csi=852 siz=32 off=0
kxsbbbfp=7f56184dfa68 bln=32 avl=21
flg=09
value="CHECKPRIVRLS_SELECTPF"
EXEC
#140007748108528:c=0,e=90,p=0,cr=0,cu=0,mis=0,r=0,dep=3,og=1,plh=1049820942,tim=1471928680661567
FETCH
#140007748108528:c=0,e=48,p=0,cr=8,cu=0,mis=0,r=1,dep=3,og=1,plh=1049820942,tim=1471928680661636
CLOSE
#140007748108528:c=0,e=1,dep=3,type=3,tim=1471928680661664
BINDS #140007748108528:
Bind#0
oacdty=01 mxl=32(04) mxlc=00 mal=00 scl=00 pre=00
oacflg=03 fl2=1206001 frm=01 csi=852 siz=32 off=0
kxsbbbfp=7f561818c1f0 bln=32 avl=04
flg=05
value="JZFP"
Bind#1
oacdty=01 mxl=32(09) mxlc=00 mal=00 scl=00 pre=00
oacflg=13 fl2=206001 frm=01 csi=852 siz=32 off=0
kxsbbbfp=7f56184df238 bln=32 avl=09
flg=09
value="AH02_2014"
Bind#2
oacdty=01 mxl=32(30) mxlc=00 mal=00 scl=00 pre=00
oacflg=13 fl2=206001 frm=01 csi=852 siz=32 off=0
kxsbbbfp=7f56184dfa68 bln=32 avl=24
flg=09
value="CHECKPRIVRLS_SELECTPROPF"
EXEC
#140007748108528:c=0,e=81,p=0,cr=0,cu=0,mis=0,r=0,dep=3,og=1,plh=1049820942,tim=1471928680661775
FETCH
#140007748108528:c=0,e=19,p=0,cr=8,cu=0,mis=0,r=1,dep=3,og=1,plh=1049820942,tim=1471928680661803
CLOSE
#140007748108528:c=0,e=1,dep=3,type=3,tim=1471928680661824
EXEC
#140007751881456:c=1000,e=431,p=0,cr=16,cu=0,mis=0,r=1,dep=2,og=4,plh=0,tim=1471928680661837
CLOSE
#140007751881456:c=0,e=9,dep=2,type=3,tim=1471928680661875
PARSE
#140007749758088:c=0,e=15,p=0,cr=0,cu=0,mis=0,r=0,dep=2,og=1,plh=0,tim=1471928680661930
问题可能就出现在这条drop语句上，我们尝试手动执行该条删除信息：
SQL> drop table JZFP.AH02_2014 cascade
constraints purge force;
drop table JZFP.AH02_2014 cascade
constraints purge force
*
ERROR at line 1:
ORA-00604: error occurred at recursive SQL
level 1
ORA-01422: exact fetch returns more than
requested number of rows
果不其然，删除这张表出现的错误信息与删除用户的错误信息时一致的，这绝对不是偶然，我们继续查看该表的相关信息：
首先查看表结构：
SQL> desc jzfp.ah02_2014;
Name
Null? Type
-----------------------------------------------------------------------------------------------------------------
-------- ----------------------------------------------------------------------------
AHH002
NOT NULL VARCHAR2(50)
AAA001
VARCHAR2(50)
AAD001
VARCHAR2(50)
AAD002
VARCHAR2(20)
AAD003
VARCHAR2(50)
AAD004
VARCHAR2(50)
AAD005
VARCHAR2(50)
AAD006
VARCHAR2(50)
AAD007
VARCHAR2(100)
AAD008
VARCHAR2(100)
AAD009
VARCHAR2(100)
AAD010
VARCHAR2(100)
AAD011
VARCHAR2(20)
AAD012
VARCHAR2(100)
AAD013
VARCHAR2(100)
AAH007
VARCHAR2(50)
AAH001
VARCHAR2(50)
AAH002
DATE
AAH008
VARCHAR2(50)
AAH003 VARCHAR2(50)
AAH004
DATE
AAH005 VARCHAR2(200)
AAH006
VARCHAR2(10)
AAD015 VARCHAR2(10)
AAD014
VARCHAR2(10)
AAD016
VARCHAR2(10)
MEMBER_NO
VARCHAR2(50)
CHANGE_TIME
VARCHAR2(20)
CREATE_TIME
VARCHAR2(20)
DELETE_TIME
VARCHAR2(20)
STATUS
CHAR(1)
HELP_TYPE
CHAR(2)
POLITICS_STATUS
VARCHAR2(2)
AZC005
VARCHAR2(12)
XYJR
CHAR(2)
DBYLBX
CHAR(2)
OLD_AAD015 VARCHAR2(10)
REDUCE_STATE
CHAR(1)
SQL> select count(*) from jzfp.ah02_2014;
COUNT(*)
----------
0
这儿说明该表示正常存在的，而且只有0条信息，接着查看该表的统计信息：
END OF STMT
PARSE #140007749758088:c=7999,e=8907,p=0,cr=16,cu=0,mis=1,r=0,dep=0,og=1,plh=0,tim=1471929977717985
PARSE
#140007751390232:c=0,e=19,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,plh=0,tim=1471929977718142
BINDS #140007747989728:
Bind#0
oacdty=01 mxl=32(04) mxlc=00 mal=00 scl=00 pre=00
oacflg=03 fl2=1206001 frm=01 csi=852 siz=32 off=0
kxsbbbfp=7f56186d3f68 bln=32 avl=04
flg=05
value="JZFP"
Bind#1
oacdty=01 mxl=32(19) mxlc=00 mal=00 scl=00 pre=00
oacflg=13 fl2=206001 frm=01 csi=852 siz=32 off=0
kxsbbbfp=7f56184df238 bln=32 avl=19
flg=09
value="PK_AH02_2014_AHH002"
Bind#2
oacdty=01 mxl=32(30) mxlc=00 mal=00 scl=00 pre=00
oacflg=13 fl2=206001 frm=01 csi=852 siz=32 off=0
内容2：
=====================
PARSING IN CURSOR #140007749746360 len=56
dep=1 uid=0 oct=26 lid=0 tim=1471930052112942 hv=2415965579 ad='edaf19e00'
sqlid='5mrrd3f801dcb'
LOCK TABLE
"JZFP"."AH02_2014" IN EXCLUSIVE MODE NOWAIT
END OF STMT
PARSE
#140007749746360:c=2000,e=2810,p=0,cr=17,cu=0,mis=1,r=0,dep=1,og=4,plh=0,tim=1471930052112941
EXEC
#140007749746360:c=0,e=39,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,plh=0,tim=1471930052113043
CLOSE
#140007749746360:c=0,e=3,dep=1,type=0,tim=1471930052113080
CLOSE
#140007749732656:c=0,e=5,dep=1,type=0,tim=1471930052113156
我们手动执行以上内容1中标黑的部分，执行都会提示错误信息，由于网络原因，断开连接导致部分信息未能粘出来，但是这两条信息都是无关紧要的，我接着查询一下该表的定义信息：
CREATE TABLE "JZFP"."AH02_2014"
( "AHH002" VARCHAR2(50) NOT NULL ENABLE,
"AAA001" VARCHAR2(50),
"AAD001" VARCHAR2(50),
"AAD002" VARCHAR2(20),
"AAD003" VARCHAR2(50),
"AAD004" VARCHAR2(50),
"AAD005" VARCHAR2(50),
"AAD006" VARCHAR2(50),
"AAD007" VARCHAR2(100),
DBMS_METADATA.GET_DDL('TABLE','AH02_2014','JZFP')
--------------------------------------------------------------------------------
"AAD008" VARCHAR2(100),
"AAD009" VARCHAR2(100),
"AAD010" VARCHAR2(100),
"AAD011" VARCHAR2(20),
"AAD012" VARCHAR2(100),
"AAD013" VARCHAR2(100),
"AAH007" VARCHAR2(50),
"AAH001" VARCHAR2(50),
"AAH002" DATE,
"AAH008" VARCHAR2(50),
"AAH003" VARCHAR2(50),
DBMS_METADATA.GET_DDL('TABLE','AH02_2014','JZFP')
--------------------------------------------------------------------------------
"AAH004" DATE,
"AAH005" VARCHAR2(200),
"AAH006" VARCHAR2(10),
"AAD015" VARCHAR2(10),
"AAD014" VARCHAR2(10),
"AAD016" VARCHAR2(10),
"MEMBER_NO" VARCHAR2(50),
"CHANGE_TIME" VARCHAR2(20),
"CREATE_TIME" VARCHAR2(20),
"DELETE_TIME" VARCHAR2(20),
"STATUS" CHAR(1) DEFAULT 1,
DBMS_METADATA.GET_DDL('TABLE','AH02_2014','JZFP')
--------------------------------------------------------------------------------
"HELP_TYPE" CHAR(2),
"POLITICS_STATUS" VARCHAR2(2),
"AZC005" VARCHAR2(12),
"XYJR" CHAR(2),
"DBYLBX" CHAR(2),
"OLD_AAD015" VARCHAR2(10),
"REDUCE_STATE" CHAR(1),
CONSTRAINT "PK_AH02_2014_AHH002" PRIMARY KEY ("AHH002")
USING INDEX PCTFREE 10 INITRANS 2 MAXTRANS 255 COMPUTE STATISTICS
STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1
DBMS_METADATA.GET_DDL('TABLE','AH02_2014','JZFP')
--------------------------------------------------------------------------------
BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT CELL_FLASH_CACHE DEFAULT)
TABLESPACE "GSJZFP" ENABLE
) SEGMENT CREATION IMMEDIATE
PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255
NOCOMPRESS LOGGING
STORAGE(INITIAL 1207959552 NEXT 8192 MINEXTENTS 1 MAXEXTENTS 2147483645
PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1
BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT CELL_FLASH_CACHE DEFAULT)
TABLESPACE "GSJZFP"
通过该表的定义信息，查看不到有什么异常，我们联系开发尝试重建该表，过了几分钟，开发反馈回来的信息时该表无法创建，也无法删除。好吧，到此真的是很无奈，我们只能继续查看跟踪文件，看能不能查到蛛丝马迹，果然，黄天不负有心人啊，O(∩_∩)O哈哈~，通过不断的尝试，在跟踪文件中发现如下信息：
=====================
PARSING IN CURSOR #140559996906600 len=123
dep=1 uid=0 oct=3 lid=0 tim=1471936427212820 hv=2356131727 ad='edc06fc30'
sqlid='1h1ymb266zdwg'
select log, flag,
to_date('4000-01-01:00:00:00','YYYY-MM-DD:HH24:MI:SS') from sys.mlog$ where mowner = :1 and master
= :2
END OF STMT
PARSE
#140559996906600:c=1000,e=70,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,plh=3625463896,tim=1471936427212820
BINDS #140559996906600:
Bind#0
oacdty=01 mxl=32(04) mxlc=00 mal=00 scl=00 pre=00
oacflg=10 fl2=0001 frm=01 csi=00 siz=64 off=0
kxsbbbfp=7fd6acaf5fc8 bln=32 avl=04
flg=05
value="JZFP"
Bind#1
oacdty=01 mxl=32(09) mxlc=00 mal=00 scl=00 pre=00
oacflg=10 fl2=0001 frm=01 csi=00 siz=0 off=32
kxsbbbfp=7fd6acaf5fe8 bln=32 avl=09
flg=01
value="AH02_2014"
EXEC
#140559996906600:c=0,e=69,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,plh=3625463896,tim=1471936427212922
FETCH
#140559996906600:c=0,e=75,p=0,cr=2,cu=0,mis=0,r=1,dep=1,og=4,plh=3625463896,tim=1471936427213005
STAT #140559996906600 id=1 cnt=2 pid=0
pos=1 obj=650 op='TABLE ACCESS CLUSTER MLOG$ (cr=2 pr=0 pw=0 time=60 us cost=1
size=57 card=1)'
STAT #140559996906600 id=2 cnt=1 pid=1
pos=1 obj=649 op='INDEX UNIQUE SCAN I_MLOG# (cr=1 pr=0 pw=0 time=21 us cost=0
size=0 card=1)'
CLOSE
#140559996906600:c=0,e=3,dep=1,type=1,tim=1471936427213061
EXEC
#140559997371296:c=19997,e=19527,p=0,cr=34,cu=9,mis=0,r=0,dep=0,og=1,plh=0,tim=1471936427213085
ERROR #140559997371296:err=604 tim=1471936427213094
*** 2016-08-23 15:14:02.256
CLOSE
#140559997371296:c=0,e=8,dep=0,type=0,tim=1471936442256880
=====================
PARSING IN CURSOR #140559997371296 len=33
dep=0 uid=0 oct=42 lid=0 tim=1471936442257737 hv=525901419 ad='7fd6acb3fe00' sqlid='aam2chsgpj7mb'
alter session set sql_trace=false
END OF STMT
PARSE
#140559997371296:c=1000,e=740,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=1,plh=0,tim=1471936442257736
EXEC
#140559997371296:c=0,e=60,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,plh=0,tim=1471936442257904
*** 2016-08-23 15:14:20.842
CLOSE
#140559997371296:c=0,e=7,dep=0,type=0,tim=1471936460841995
执行以上信息中标黑的部分：
SQL> select log, flag,MASTER from
sys.mlog$ where mowner = 'JZFP' and master = 'AH02_2014';
LOG FLAG MASTER
------------------------------ ----------
------------------------------
MLOG$_AH02_2014 270369 AH02_2014
MLOG$_AH02_2014 270369 AH02_2014
发现居然出来两条结果一模一样的记录，根据之前的错误提示中，可知出现递归错误的原因就是出现多值条件，这也许就是问题的根源了，好吧，先来介绍一下sys.mlog$。
Changing
a Materialized View Group's Master Site
To change the master site of a materialized
view group at a level 1 materialized view site to another master site, call
the SWITCH_MVIEW_MASTERprocedure in the DBMS_REPCAT package, as shown in the following example:
BEGIN
gname => 'hr_repg',
master => 'orc3.example.com');
END;
/
In this example, the master site for the hr_repg replication group is changed to the orc3.example.com master site. You must call this procedure at the
materialized view site whose master site you want to change. The new database
must be a master site in the replication environment. When you call this
procedure, Oracle uses the new master to perform a full refresh of each
materialized view in the local materialized view group. Ensure that you have
set up the materialized view site to use the new master site before you run
the SWITCH_MVIEW_MASTER procedure.
The entries in theSYS.SLOG$table at the old master site for the switched
materialized view are not removed. As a result, the materialized view log (MLOG$table) of the switched updatable materialized view at
the old master site has the potential to grow indefinitely, unless you purge it
by callingDBMS_MVIEW.PURGE_LOG.
Note:
You
cannot switch the master of materialized views that are based on other
materialized views (level 2 and greater materialized views). Such a materialized
view must be dropped and re-created to base it on a different master.
这是从Oracle官方文档上找到的相关信息，大概意思就是说该表中的数据是oracle为了同步基表和物化视图之间的数据的，当基表的数据发生变化，在日志表中就会产生数据。等oracle将变化同步到物化视图后，日志表中的数据会自动清除。一般情况下不建议手工删除该表中的数据。
这个表一般是通过create materialized view log on与drop materialized view log操作产生，只要有这样的表存在，就一定是做过类似的操作，不是你做的也是别人做的。
通过跟开发交流，这张表上确实存在物化视图，而且将物化视图删掉之后，该表还是删除不掉，那么先删除sys.mlog$中的重复记录：
SQL> select log, flag,MASTER from
sys.mlog$ where mowner = 'JZFP' and master = 'AH02_2014' and rownum=1;
LOG FLAG MASTER
------------------------------ ----------
------------------------------
MLOG$_AH02_2014 270369 AH02_2014
SQL> delete from sys.mlog$ where mowner
= 'JZFP' and master = 'AH02_2014' and rownum=1;
1 row deleted.
SQL> commit;
Commit complete.
SQL> select log, flag,MASTER from
sys.mlog$ where mowner = 'JZFP' and master = 'AH02_2014';
LOG FLAG MASTER
------------------------------ ----------
------------------------------
MLOG$_AH02_2014 270369 AH02_2014
删除完确认值留存一条日志记录，然后再删除该表：
SQL> drop table jzfp.ah02_2014;
Table dropped.
SQL>
可以看到该表正常删除。还有几张表也是删除不掉，按照这个过程均一一删除，接着删除用户再试试：
SQL> drop user jzfp cascade;
drop user jzfp cascade
*
ERROR at line 1:
ORA-01940: cannot drop a user that is
currently connected
错误提示信息已经不是之前的信息，这个错误信息的意思是该用户有当前正在链接的会话，查询与该用户有关的会话，kill即可。过程如下：
SQL> select sid,serial# from v$session
where USERNAME='JZFP';
SID SERIAL#
---------- ----------
862 1597
912
857
2147 4509
2954 32089
SQL> alter system kill session
'862,1597';
System altered.
SQL> alter system kill session
'912,857';
System altered.
SQL> alter system kill session
'2147,4509';
System altered.
SQL> alter system kill session
'2954,32089';
System altered.
SQL> drop user jzfp cascade;
User dropped.
可以看到jzfp用户正常删除。
Trace文件名：
jzfpysdb1_ora_18493.trc
jzfpysdb1_ora_25323.trc
文章浏览阅读3.2k次。本文研究全球与中国市场分布式光纤传感器的发展现状及未来发展趋势，分别从生产和消费的角度分析分布式光纤传感器的主要生产地区、主要消费地区以及主要的生产商。重点分析全球与中国市场的主要厂商产品特点、产品规格、不同规格产品的价格、产量、产值及全球和中国市场主要生产商的市场份额。主要生产商包括：FISO TechnologiesBrugg KabelSensor HighwayOmnisensAFL GlobalQinetiQ GroupLockheed MartinOSENSA Innovati_预计2026年中国分布式传感器市场规模有多大
文章浏览阅读1.1k次，点赞2次，收藏12次。常用组合逻辑电路结构——为IC设计的延时估计铺垫学习目的：估计模块间的delay，确保写的代码的timing 综合能给到多少HZ，以满足需求！_基4布斯算法代码
文章浏览阅读3.3k次，点赞3次，收藏5次。OpenAI Manager助手（基于SpringBoot和Vue）_chatgpt网页版
文章浏览阅读2.2k次。USACO自1992年举办，到目前为止已经举办了27届，目的是为了帮助美国信息学国家队选拔IOI的队员，目前逐渐发展为全球热门的线上赛事，成为美国大学申请条件下，含金量相当高的官方竞赛。USACO的比赛成绩可以助力计算机专业留学，越来越多的学生进入了康奈尔，麻省理工，普林斯顿，哈佛和耶鲁等大学，这些同学的共同点是他们都参加了美国计算机科学竞赛（USACO)，并且取得过非常好的成绩。适合参赛人群USACO适合国内在读学生有意向申请美国大学的或者想锻炼自己编程能力的同学，高三学生也可以参加12月的第_usaco可以多次提交吗
文章浏览阅读394次。1.1 存储程序1.2 创建存储过程1.3 创建自定义函数1.3.1 示例1.4 自定义函数和存储过程的区别1.5 变量的使用1.6 定义条件和处理程序1.6.1 定义条件1.6.1.1 示例1.6.2 定义处理程序1.6.2.1 示例1.7 光标的使用1.7.1 声明光标1.7.2 打开光标1.7.3 使用光标1.7.4 关闭光标1.8 流程控制的使用1.8.1 IF语句1.8.2 CASE语句1.8.3 LOOP语句1.8.4 LEAVE语句1.8.5 ITERATE语句1.8.6 REPEAT语句。_mysql自定义函数和存储过程
文章浏览阅读188次。半导体二极管——集成电路最小组成单元。_本征半导体电流为0
文章浏览阅读2.8k次，点赞3次，收藏18次。游戏水面特效实现方式太多。咱们这边介绍的是一最简单的UV动画（无顶点位移），整个mesh由4个顶点构成。实现了水面效果（左图），不动代码稍微修改下参数和贴图可以实现岩浆效果（右图）。有要思路是1，uv按时间去做正弦波移动2，在1的基础上加个凹凸图混合uv3，在1、2的基础上加个水流方向4，加上对雾效的支持，如没必要请自行删除雾效代码(把包含fog的几行代码删除)S..._unity 岩浆shader
文章浏览阅读5k次。广义线性模型是线性模型的扩展，它通过连接函数建立响应变量的数学期望值与线性组合的预测变量之间的关系。广义线性模型拟合的形式为：其中g(μY)是条件均值的函数（称为连接函数）。另外，你可放松Y为正态分布的假设，改为Y 服从指数分布族中的一种分布即可。设定好连接函数和概率分布后，便可以通过最大似然估计的多次迭代推导出各参数值。在大部分情况下，线性模型就可以通过一系列连续型或类别型预测变量来预测正态分布的响应变量的工作。但是，有时候我们要进行非正态因变量的分析，例如：（1）类别型.._广义线性回归模型
文章浏览阅读69次。环境保护、 保护地球、 校园环保、垃圾分类、绿色家园、等网站的设计与制作。 总结了一些学生网页制作的经验：一般的网页需要融入以下知识点：div+css布局、浮动、定位、高级css、表格、表单及验证、js轮播图、音频 视频 Flash的应用、ul li、下拉导航栏、鼠标划过效果等知识点，网页的风格主题也很全面：如爱好、风景、校园、美食、动漫、游戏、咖啡、音乐、家乡、电影、名人、商城以及个人主页等主题，学生、新手可参考下方页面的布局和设计和HTML源码（有用点赞△） 一套A+的网_垃圾分类网页设计目标怎么写
文章浏览阅读614次，点赞7次，收藏11次。之前找到一个修改 exe 中 DLL地址 的方法, 不太好使,虽然能正确启动, 但无法改变 exe 的工作目录,这就影响了.Net 中很多获取 exe 执行目录来拼接的地址 ( 相对路径 ),比如 wwwroot 和 代码中相对目录还有一些复制到目录的普通文件 等等,它们的地址都会指向原来 exe 的目录, 而不是自定义的 “lib” 目录,根本原因就是没有修改 exe 的工作目录这次来搞一个启动程序,把 .net 的所有东西都放在一个文件夹,在文件夹同级的目录制作一个 exe._.net dll 全局目录
文章浏览阅读1.5k次。本文为转载，原博客地址：http://blog.csdn.net/hujingshuang/article/details/46910259简介 BRIEF是2010年的一篇名为《BRIEF:Binary Robust Independent Elementary Features》的文章中提出，BRIEF是对已检测到的特征点进行描述，它是一种二进制编码的描述子，摈弃了利用区域灰度..._breif description calculation 特征点
文章浏览阅读4.1k次，点赞21次，收藏79次。本文是《基于SpringBoot的房屋租赁管理系统》的配套原创说明文档，可以给应届毕业生提供格式撰写参考，也可以给开发类似系统的朋友们提供功能业务设计思路。_基于spring boot的房屋租赁系统论文