Yes, just as I thought.

The clue is in the error statement:

**Failed SQL: /* ~~QC */ DELETE FROM LOCKS WHERE LK_SESSION_ID=52411;
[Mercury][SQLServer JDBC Driver][SQLServer]The transaction log for database 'default_myProject_db' is full. To find out why space in the log cannot be reused, see the log_reuse_wait_desc column in sys.databases;**

According to SQL-Server general problems, the Log file had a size limit and had run out, But it should be set to GROW automatically.

If you examine drive where SQL-Server MDB and LOG files are stored, check it's available free space, it might be OUT OF SPACE.

After deleting a few extranerous files and backups, freeing up space, the error usually goes away.

So, it was not really SQL having a size limit, you are probably out of disk space on the SQL-Server.

Soapy,

I have seen tthis before.

Can you please post the error details?

PT

Messages:
Failed to Run Query;
Failed to execute the query;
Failed SQL: /* ~~QC */ DELETE FROM LOCKS WHERE LK_SESSION_ID=52411;
[Mercury][SQLServer JDBC Driver][SQLServer]The transaction log for database default_myProject_db' is full. To find out why space in the log cannot be reused, see the log_reuse_wait_desc column in sys.databases;

Stack Trace:
java.sql.SQLException: Failed SQL: /* ~~QC */ DELETE FROM LOCKS WHERE LK_SESSION_ID=52411;
[Mercury][SQLServer JDBC Driver][SQLServer]The transaction log for database 'default_myProject_db' is full. To find out why space in the log cannot be reused, see the log_reuse_wait_desc column in sys.databases
at com.mercury.optane.core.db.CAbsStatement.createSQLExceptionWithSQLStatement(CAbsStatement.java:214)
at com.mercury.optane.core.db.CAbsStatement.doExecute(CAbsStatement.java:197)
at com.mercury.optane.core.db.CTdPreparedStatement.executeUpdate(CTdPreparedStatement.java:540)
at com.mercury.td.saserver.api.logics.CAdminLogic.runQuery(CAdminLogic.java:636)
wrapped in com.mercury.optane.core.CTdException: Failed to execute the query
at com.mercury.td.saserver.api.logics.CAdminLogic.runQuery(CAdminLogic.java:648)
at com.mercury.td.saserver.requests.RunQuery.execute(RunQuery.java:27)
at com.mercury.optane.core.web.RequestsDispatcher.execute(RequestsDispatcher.java:90)
wrapped in com.mercury.optane.core.CTdException: Failed to Run Query
at com.mercury.optane.core.web.RequestsDispatcher.execute(RequestsDispatcher.java:97)
at com.mercury.td.web.CAbsServlet.executeFunction(CAbsServlet.java:483)
at com.mercury.td.web.CAbsServlet.processRequest(CAbsServlet.java:475)
at com.mercury.td.web.CAbsServlet.doPost(CAbsServlet.java:349)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:637)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at com.hp.qc.core.utils.gzipfilter.GZIPFilter.doFilter(GZIPFilter.java:30)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at com.mercury.optane.core.state.ServerStatusFilter.doFilter(ServerStatusFilter.java:33)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:235)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
at org.apache.coyote.http11.Http11Protocol$Http11Connec

Wow!
It was the disk space on the SQL-Server.

We freed up some space and it started working agin in QC automatically.

Thanks PT!

Hi Folks,

I'm experiencing the same issue but we're on an Oracle 11.g database. I had our DBAs check the space and thats not the issue for us. Does anyone know what else could be the cause?

I've read that this is a known bug in patch 6 for Performance Center when it's integrated with ALM (like ours is) and it's due to scheduled times in Lab Management but not sure how this would affect users being able to add folders in ALM.

Any thoughts or suggestions on this would really help as the users are getting very irritated.

Thanks
Steve