When you try and do a substring on a value returned from a database, you may get an error about the object not supporting the property.
If you are trying to run a test case or test set and you receive the following error:
Database constraint violation occurred [APPLICATION.Business.EntityConstraintViolationException]
An error occurred while updating the entries. See the inner exception for details. [System.Data.UpdateException]
Violation of PRIMARY KEY constraint 'XPKTST_ARTIFACT_CUSTOM_PROPERTY'. Cannot insert duplicate key in object 'dbo.TST_ARTIFACT_CUSTOM_PROPERTY'.
The statement has been terminated. [System.Data.SqlClient.SqlException]
Then this article provides the solution for you.
Some of our customers wanted to know that we delete the data in the SpiraTest, SpiraPlan, and SpiraTeam tables when we delete a project. This article outlines the approximate order in Spira v184.108.40.206.
When you install SpiraTest, SpiraTeam, SpiraPlan, or KronoDesk on premise, you have a choice in different ways to configure SQL Server. Every situation is different, but this article presents some recommendations.
One common requirement is to run a query in an application being tested and verify that the data on the screen matches the data in the application. This article explains the recommended process for doing this.
With the latest version of SpiraTest, SpiraPlan and SpiraTeam, we have provided a simple button in the Data Tools section that lets you rebuild the database indexes using the same script that we published in KB10. However sometimes the database is so large that the execution takes longer than the 30 minutes allowed by the application, or you want more control over the fragmentation levels that trigger a rebuild. This article provides guidance and a more advanced script for power users.
As part of the v5.0 update to SpiraTest, SpiraPlan and SpiraTeam, we made major changes to the database structure to improve performance and usability as well as lay the foundation for v5.1, v5.2 and v5.3 due out later this year. Customers using custom reports
that relied on the old v4.2 database structure will need to modify their custom reports.
When connecting from Spira or Krono installed on a separate application server to a remote SQL server, you may have difficulties connecting. This article describes the steps for making sure that your SQL Server can be accessed remotely.
This usually just means that the restored database just needs to be linked to the existing database server login. This can be done by executing the appropriate SQL command listed below:
This is a common need, since you may have installed SpiraTest, SpiraPlan, SpiraTeam, or KronoDesk on a workstation to evaluate its capabilities and now need to install it on a production server for real use, but you don't want to lose all your existing data.
This article answers some common questions about which databases you can run SpiraTest, SpiraPlan, SpiraTeam and KronoDesk on, and where you can get them from.
Sometimes when you are running Rapise tests you need to run direct database queries to prepare the data in the test application, or you need to make queries against the database to verify that some user interactions left the data in a specific state.
The sample script below illustrates how you can call database queries directly from the Rapise scripting editor:
The steps to perform when needing to move the database to another SQl Server, or when changing the DNS name of your SQL Server.
This article describes the process and steps for moving your SpiraTest, SpiraPlan or SpiraTeam database from one computer to another.
The article will refer to SpiraTeam, but it applies equally to the other products.