August 2002
This patch addresses the following defects:
Category |
RATLC ID |
Description / Comments |
General |
00027412 |
After multiple generations, Word consumes a lot of memory and
does not release it. With each generation, SoDA gathers a lot of data to create a
report, causing a large amount of memory usage. This patch ensures that
memory is released upon exit. |
|
00365165 |
Cannot evaluate Open Statement error when generating with Specific Req type |
|
00365210 |
Unable to Generate Report
a second time |
|
00365215 |
Not prompted to save
changes when you open template by double-clicking |
|
00365304 |
RDSI server error in Locate Artifact |
|
00365428 |
Error Dialog - RDSI Error cannot locate artifact when Class not found - No Error Report created |
|
00365638 |
Word-calculated fields are not updated when the Generate Document command is used |
|
|
|
SoDA and ClearQuest |
00365183 |
Dynamic fields that
contain a dash are not recognized by SoDA |
|
|
|
SoDA and TeamTest |
NOTE: |
Changes to the TeamTest
Domain to support these fixes are described at the end of this document. |
|
00011577 |
ImplementingScript
confuses SoDA users |
|
00031026 |
Unable to retrieve design editor information in Test Manager |
|
|
|
SoDA and Requisite Pro |
00027252 |
A RequisitePro .mdb file increases in size with SoDA generation With each generation,
the RequisitePro database can grow as it writes data to temporary tables to
improve the performance of queries. Additionally, Microsoft Access allocates
data pages as needed to accommodate that growth. When you exit SoDA, the data
in the temporary tables is removed from the database. However, Access does
not physically remove the empty data pages. Therefore, when you exit SoDA the
size of the RequisitePro database could be larger than it was before you
started SoDA. This patch ensures that exiting SoDA takes less time and that
only the empty data pages remain in the database. This allows for successful
database compaction, which can be performed as needed – manually with
Microsoft Access, or automatically with Requisite Pro. RequisitePro has code to
automatically compact the database. Before a compact is performed, several
pieces of information are read from the project's .RQL file. An example is
below: [DBMaint] In the DBMaint section, the CompactBaselineSize and
CompactThresholdSize are important. ·
The
CompactBaselineSize is the size of the database recorded when the DB was new
after first compacted. ·
The
CompactThresholdSize is the threshold for DB file size increase that triggers
the compact (in mB). In this example, the compact will run when the MDB file
increases by 10 mB over the CompactBaselineSize. |
|
00027414 |
RequisitePro Database is locked even after document generation
is finished |
|
00365128 |
Opening a deleted RequisitePro requirement gives unexpected word
error |
SoDA and Word 97 |
00365164 |
Unexpected Word Error during generation with GenSuffix=<blank> in soda.ini On low powered machines,
there is an occasional graphic insertion problem where the first time a
document is generated either a generic image (gray square) appears, or the
correct image appears but is scaled incorrectly. The workaround is to
generate the document again. However, if you see the generic image and the Word error “cannot
open the graphics file,” the graphic has been corrupted and you cannot
generate the document again. Instead, you must return to the template where you
see the gray square and no error message from Word. |
|
00365305 |
Unexpected Word Error during generate document |
|
|
|
SoDA and Word 2002 |
00031308 |
The Show/Hide state of the
SoDA command display is not restored when there is an error condition |
|
00365191 |
In the Hebrew environment,
some text in repeated tables becomes hidden |
|
00365193 |
The Show/Hide state of the
SoDA command display is not saved correctly |
|
00365263 |
The selection changes
after hiding the SoDA commands, which makes it difficult to compose SoDA
templates |
|
00365665 |
Data ends up in the last table when the Generate Document command is used NOTE: There
continues to be a limitation when using Generate Document on an already
generated document that contains repeated rows in tables, if the tables
need to include more rows. In this case, SoDA incorrectly changes the
document when adding additional rows to the table. Namely, the new row will
be added but the surrounding rows will be corrupted. This issue is being
tracked as RATLC00365701. |
Before you install the
patch, you must clean and compact the RequisitePro database to remove temporary
data that may have been left behind.
1.
Make
sure no one is logged into the RequisitePro database (*.mdb) with any
application.
2.
Make
a backup of the RequisitePro Database.
3.
When
no one is connected to the database, open the database with Access.
4.
For
each of these tables:
·
RqGenericTableTemp
·
RqHierarchyFinalOrderTemp
·
RqHierarchyOrderedLevelsTemp
·
RqHierarchTableTemp
·
RqTraceTableTemps
Perform these steps to clean out
all the temporary data (do NOT remove the tables themselves):
a)
Open
the table.
b)
Select
all the data in the table.
c)
Delete
the data from the table (Edit > Delete).
5.
Compact
the database by selecting Tools > Database Utilities > Compact and
Repair Database.
6.
Save
your changes, and exit Access.
NOTE: If you reinstall OM20 after
installing this patch, you must also reinstall the patch.
1.
Extract
the zip file.
2.
Copy soda2000.wll,
soda97.wll, sodaxp.wll and xmlgen.dll into <SoDA
Home>
(for example, C:\Program Files\Rational\SoDAWord).
3.
Copy RSERose.dll,
RSEClearQuest.dll, and RSETeamTest.dll into <Rational
Installation Directory\Common>
(for example, C:\Program Files\Rational\Common).
4.
Copy TeamTest.als
into <SoDA Home\domains\RDSI>
(for example, C:\Program Files\Rational\SoDA Word\domains\RDSI).
5.
If you
have ProjectConsole, also copy TeamTest.als into
<ProjectConsole Home\domains\RDSI
(for example, C:\Program Files\Rational\ProjectConsole\domains\RDSI).
6.
Open
the MS-DOS Command prompt, cd to <SoDA Home>, and run regsvr32 xmlgen.dll.
7.
At
the MS-DOS Command prompt, cd to <Common>, and run
regsvr32 RSERose.dll RSEClearQuest.dll RSETeamTest.dll.
Even with the renaming
changes described below, existing templates are still correctly supported.
ProjectConsole Note: You will not see the name changes
below in the ProjectConsole Collector or Browser.
Step is a new class that
represents a procedural step that may be 1) a design step for a TestCase or
ConfiguredTestCase, or 2) a manual step in a test script. Steps are presented
in the Test Manager GUI through the Design Editor dialog and Rational
ManualTest tool.
A Step has the following
attributes:
Name |
Description |
Type |
The kind of step:
"Step" or "VP" (indicating VerificationPoint) |
Note |
The note attached to the
step, if any (multi-line). |
Description |
The description of the
step (single-line) |
The following
relationships were renamed for clarity and consistency:
Original Name |
New Name |
ImplementingSuite |
AutomatedImplementingSuite |
ImplementingScript |
AutomatedImplementingScript |
Descriptions of
relationships:
Name |
Kind |
Description |
AutomatedImplementingSuite |
0..1 |
Indicates the Suite (if any)
in the Automatic Implementation field of the TestCase Properties |
AutomatedImplementingScript |
0..1 |
Indicates the Script (if
any) in the Automatic Implementation field of the TestCase Properties |
New relationship:
Name |
Kind |
Description |
|
DesignSteps |
0..n |
Indicates the sequence
of design steps (if any) associated with the TestCase |
|
ManualImplementingScript |
0..1 |
Indicates the Script (if
any) in the Manual Implementation field of the TestCase Properties |
The following
relationships were renamed for clarity and consistency:
Original Name |
New Name |
ImplementingSuite |
AutomatedImplementingSuite
|
ImplementingScript |
AutomatedImplementingScript
|
Descriptions of relationships:
Name |
Kind |
Description |
AutomatedImplementingSuite |
0..1 |
Indicates the Suite (if
any) in the Automatic Implementation field of the ConfiguredTestCase
Properties |
AutomatedImplementingScript |
0..1 |
Indicates the Script (if
any) in the Automatic Implementation field of the TestCase Properties |
New relationships:
Name |
Kind |
Description |
ManualImplementingScript |
0..1 |
Indicates the Script (if
any )in the Manual Implementation field of the Configured TestCase Properties |
DesignSteps |
0..n |
Indicates the sequence
of design steps (if any) associated with the ConfiguredTestCase |
The following relationship
was renamed for clarity. This relationship is made obsolete by the addition of
the Step class and Steps relationship. It is retained for upward compatibility.
Original Name |
New Name |
ManualSteps |
StepDescriptions |
New relationship:
Name |
Kind |
Description |
Steps |
0..n |
Indicates the sequence
of manual Steps (if any) associated with the Script |