---

Ich plane in der kommenden Woche von Intralink 3.2 auf die 3.3 umzusteigen bevor wir dann auf Wildfire updaten können.
Weiss jemand, welche Unterschiede zwischen der 2002470, der 2002471 und der (noch nicht  veröffentlichten) 2003290 bestehen? Lohnt es sich auf die 20032090 zu warten?

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

von der ptc-seite:

Der Update Advisor ist dazu gedacht Ihnen Informationen zur Hand zu geben, die dabei helfen herauszufinden, welchen Wert ein evtl. geplantes Update auf eine bestimmte Version/Wochenversion hat. Er soll den TAN Tracker ersetzen.

h**p://www.ptc.com/support/support.htm

`lohnt es sich auf die 20032090 zu warten' - mal ehrich, woher soll das einer wissen? niemand hat das ding eingehend getestet (stabilitaet, perfornce), lediglich der funktionsumfang wird erklaert (neuerungen)...

... so long

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hi Hagen,

der Update Advisor ist eine nette Sache. Aus deiner Antwort nehme ich herause,d ass du die beiden neueren Intralink-Versionene auch nicht gesehen bzw. Infos darüber gelesen hast?

Gruesse, Calvin

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

http://www.ptc.com/support/notice/3.3ReIssueNotification-final_en.pdf http://www.ptc.com/cs/doc/pds_calendar.pdf
Das habe ich gefunden

------------------
Servus
Alois

[Diese Nachricht wurde von anagl am 08. Oktober 2003 editiert.]

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Danke Alois,

scheinbar gibt es tatsächlich noch keine genaueren Infos über die beiden neuen Versionen. Der Kalender ist auf jeden Fall für die Zukunft interessant - auch wenn man da nicht drauf bauen kann...

Grüße, Calvin

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo Zusammen,

das größte Test-Feld ist die Anwenderschaft. Also werden neue Fehler zu neuen Software-Versionen erst auffallen, wenn die Anwender damit arbeiten.
Möglichkeit a) Warten bis die Version eine Weile auf dem Markt ist
Möglichkeit b) Eigene Test-Umgebung aufbauen und selber testen.

Gruß

Bernhard Veckes

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo,

bei einigen intensiveren Tests, die über die Anpassung der Schulungsunterlagen auf die 3.3 hinausgingen, hatte ich einige Probleme mit Familientabellen.
Klar, da gibt es die neue Funktion in Kombination mit der Wildfire, das Familientabellen immer geprüft sein müssen. Darüber hinaus ist mir jedoch aufgefallen:
a. Beim Aufruf von Generischen von der Platte wurde angemeckert, das die Familientabelle nicht geprüft war. Aber die war mal geprüft - zwar nicht in der aktuellen Sitzung, aber ganz sicher vorher, als sie erstellt wurde. Lerneffekt: Die Generischen müssen frisch in der aktuellen Wildfire geprüft sein. Irgendwann einmal geprüft reicht nicht.
b. Als ich dann die Genrischen nochmal geprüft hatte, kam eine Fehlermeldung, das dieses Modell nicht gespeichert werden konnte. Warum und wieso, wurde nicht verraten. Die Ursache oder eine Lösung habe ich noch nicht... mal weiter forschen.

Viele Grüße

Detlef Bexkens

------------------

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Zitat:

---

Original erstellt von dbexkens:

a. Beim Aufruf von Generischen von der Platte wurde angemeckert, das die Familientabelle nicht geprüft war. Aber die war mal geprüft - zwar nicht in der aktuellen Sitzung, aber ganz sicher vorher, als sie erstellt wurde. Lerneffekt: Die Generischen müssen frisch in der aktuellen Wildfire geprüft sein. Irgendwann einmal geprüft reicht nicht.
b. Als ich dann die Genrischen nochmal geprüft hatte, kam eine Fehlermeldung, das dieses Modell nicht gespeichert werden konnte. Warum und wieso, wurde nicht verraten. Die Ursache oder eine Lösung habe ich noch nicht... mal weiter forschen.

---

siehe http://www.ptc.com/cs/tan/122679.htm

--

------------------
cu
fossy
          meine kleine website

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo fossy,

danke für den Tipp mit der TAN.
Von den angebotenen 3 Lösungen im Einzelnen halte ich folgendes:

Update auf Wildfire 2003370: Ist OK für mich kleinen Berater, jedoch nicht immer ratsam für die Anwendungen in der Praxis.

config.pro Option "bump_revnum_on_retr_regen=no": Frage hierbei ist, was diese Option ausserdem noch mit anderen Modellen anstellt, was vielleicht, außer zur Lösung meines aktuellen Problems, in der Praxis einer Konstruktionsanwendung nicht erwünscht ist. Hat vielleicht jemand Erfahrung mit dieser Option?

Varianten knacken: Das ist ja wohl der Hammer, sowas in einem TAN lesen zu müssen. Kommentare hierzu spare ich mir lieber!

Viele Grüße

Detlef

------------------

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Uebrigens: nach 16h hat der Umstieg von Intralink 3.0 über die 3.2 auf die 3.3 und dann noch (wegen eines Fehlers) auf das brandneue Servicepack  für 3.3 gerappelt. Bis jetzt keine Klagen der User - bis auf eine: beim Auschecken einer Baugruppe mit 1.700 Objekten (Beziehungen: alle) bricht der Zielworkspace und mit ihm Intralink zusammen. Verbleibt die Einstellung auf "Notwendige" klappts. Die Frage ist nun ob es an der Größe oder an was anderem liegt. Habe einen call laufen und seitens PTC erst einmal folgende Antwort bekommen (obwohl 3.3 da nicht erwähnt wird...):

TAN 117722

Version: 3.1
Datecode:2001361
Machine: All
Status:  Internal

  Attempting To Check-out Very Large Assemblies In Pro/INTRALINK 3.1 or 3.2
The
Check-out Window Appears Blank When Using Dataservers On Windows Platforms.

Long Description:
  Description
  -----------------
  Attempting to check-out very large assemblies in 3.1 or 3.2 the check-out window appears blank.
  This issue can ONLY occur on dataservers installed on Windows platform.
  The issue does not occur in 3.0.
  .proi.log will show the following.
  Error Stack:
  Error 0:
  Message: Pro/INTRALINK has detected an internal error.
  Please contact Technical Support for assistance.
  Technical Support will require a detailed description of the
  actions preceeding this message. Data may also be required.
  get_LOVobjects
  Argumets:
  0: get_LOVobjects
  1: \intralink/ilapi/proilcspace/pdmlo/lovpool.cxx
  2: 193
  Error 1:
  Message: Pro/INTRALINK has detected an internal error.
  Please contact Technical Support for assistance.
  Technical Support will require a detailed description of the
  actions preceeding this message. Data may also be required.
  PDMc_QueryCursor_OQL<T>::Initialize
  Argumets:
  0: PDMc_QueryCursor_OQL<T>::Initialize
  1: \intralink/ilapi/proilbase/inc\cursor.h
  2: 390
  Error 5:
  Message: ToolKit Error : -3114
  Argumets:
  0: Error while trying to retrieve text for error ORA-03114
  Alternate Technique
  -----------------
  The problems stem from the default stacksize of the Oracle 8.1.7
'tnslsnr.exe' binary.
  Increasing that value as documented below resolves the checkout issue.
  Increase the stacksize of the binary file 'TNSLSNR.EXE' using the steps
below.
  1. Open the DOS command prompt
  2. Shutdown the dataserver using 'dbshut_ilink.bat'
  3. Change directory to '%ORACLE_HOME%\bin'
  4. Change the stacksize using the following command:
  orastack TNSLSNR.EXE 1572864
  Note that this value is in 1.5Mbytes (1024 x 1024 x 1.5).  The default
value
is 1048576 bytes
  (i.e. 1024 x 1024).
  5. Execute 'dbstart_ilink.bat' after making the change.
  Try checking-out the assembly again. If the issue still exists, repeat
steps
2-4 and increase
  the stacksize to a higher value, for example, 1835008 (which is 1024 x
1024 x
1.75).
  System Admins should increase the stack size in small increments (~.25Mb)
and
retest the
  check-out process. Setting the stacksize to an overly large value is not
recommended because
  increasing stacksize will increase the address space allocations on the
server.
  If this does not resolve the issue and is specific to only Windows 2000
clients please refer to
  TPI 120311 for a possible workaround.
  Note: With some installations, very large stack sizes (i.e. 4-8Mb) are
necessary.
  Resolution
  --------------
  N/A. See the alternate technique.

[Diese Nachricht wurde von Calvin am 11. November 2003 editiert.]

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo,
ProPDM Umsteiger (d.h. wenn irgendwann von PDM auf Intralink konvertiert wurde) sollten sich folgendes mal anschauen.

Release 3.3
TAN 122293
Datecode: 2002470

Description
-----------------
Upgrading to 3.3 or running convert_update may cause the vault path/hash name of some legacy Pro/PDM objects converted via Pro/CONVERT to change. Some objects may fail checkout or regeneration as incorrect file content may be brought into the Workspace. This TAN is for customers who have upgraded to Pro/INTRALINK From Pro/PDM using Pro/CONVERT. Please refer to the scenarios listed in the Resolution to determine if your installation is affected and how to resolve the issue.

Examples of the issue are as follows:

Prior to running convert_update or upgrading to 3.3, the following objects and paths to content exist:

widget.prt 7777@fileserver1:c:\ptc\pdm_vault1\C12345
sprocket.prt 7777@fileserver2:d:\ptc\pdm_vault2\C12345

Upgrading to 3.3 may have changed the vault path of one object to match that of the other object (the second object may now be incorrectly referenced in the vault):

widget.prt 7777@fileserver1:c:\ptc\pdm_vault1\C12345
sprocket.prt 7777@fileserver1:c:\ptc\pdm_vault1\C12345

Running convert_update may have changed the hash names of both objects to standard sequential hash numbers. In each case the metadata was updated but when the scripts were created to rename the files in the vault, one of the objects may not have been included (it may still be named Cxxxxx in the vault).

widget.prt 7777@fileserver1:c:\ptc\pdm_vault1\67890.prt
sprocket.prt 7777@fileserver2:d:\ptc\pdm_vault2\67890.prt

See TANs 115838 (http://www.ptc.com/cs/tan/115838.htm) and 113846 (http://www.ptc.com/cs/tan/113846.htm) for more information regarding the convert_update utility.

Alternate Technique
-----------------
See the Resolution.

Resolution
-----------------
The resolution of this issue is dependent upon the state of the converted legacy objects. Match the state of the implementation to one of the following scenarios in order to determine if the issue exists. Resolve the issue by following the instructions associated with the corresponding scenario.

- If the convert_update utility has been executed OR to determine if the convert_update utility has been executed:

*(Scenario 1) ... The convert_update utility was executed while in any 3.0, 3.1 or 3.2 build.

- If you have NEVER executed the convert_update utility on your Pro/INTRALINK implementation and your site ...

*(Scenario 2) ... has no immediate plans of upgrading to 3.3.

*(Scenario 3) ... is upgrading to 3.3 (Scenario referenced in Pro/INTRALINK 3.3 reship customer letter).

*(Scenario 4) ... has already implemented Pro/INTRALINK 3.3 2002470.

If you are uncertain as to which scenario applies or if your implementation does not match one outlined here, please contact Technical Support.

Scenario 1
----------
The convert_update utility was executed while in any 3.0, 3.1 or 3.2 build.

In some circumstances, the convert_update utility described in TANs 115838 and 113846 may have caused the vault path and/or hash name for legacy Pro/PDM objects converted via Pro/CONVERT to change. Please refer to TAN 122864 (http://www.ptc.com/cs/tan/122864.htm) for a resolution.

Scenario 2
----------
The convert_update utility has NEVER been executed on your Pro/INTRALINK implementation and your site has no immediate plans of upgrading to 3.3.

-Discard old copies of convert_update.
-Backup the Dataserver and vaults.
-Obtain a copy of the convert_update2_32 utility and apply if a resolution to TANs 115838 and 113846 is desired.*

*If the convert_update2_32 utility was applied, make sure to checkin at least one object before upgrading to 3.3. (SPR 1047906).

-When upgrading to 3.3, use Datecode 2002471.
-If convert_update2_32 was not applied prior to upgrading, obtain a copy of the convert_update2_33 utility and apply if a resolution to TANs 115838 and 113846 is desired.
-No further action is necessary.

Scenario 3
----------
The convert_update utility has NEVER been executed on your Pro/INTRALINK implementation and your site is upgrading to 3.3 (Scenario referenced in Pro/INTRALINK 3.3 reship customer letter).

-Discard old copies of convert_update.
-Backup the Dataserver and vaults.
-Obtain a copy of Pro/INTRALINK 3.3 2002471 and upgrade using that build.
-Obtain a copy of the convert_update2_33 utility and apply if a resolution to TANs 115838 and 113846 is desired.
-No further action is necessary

Scenario 4
----------
The convert_update utility has NEVER been executed on your Pro/INTRALINK implementation and your site has already implemented Pro/INTRALINK 3.3 2002470.

-Discard old copies of convert_update.
-Backup the Dataserver and vaults.
-Contact Technical Support to obtain a detection script (report_broken_mapname.sql).
-Save the script to a path on the Dataserver.
-Execute the report_broken_mapname.sql script from a command prompt/shell as an Administrator or Oracle user as follows:
  sqlplus system/manager @<path_to_script>report_broken_mapname.sql

*If the script returns:"PL/SQL procedure successfully completed." and no "WARNING" messages, legacy objects were not be affected by the upgrade to 3.3.

-Obtain a copy of convert_update2_33 utility and apply if a solution to TANs 115838 and 113846 is desired.
-No further action is necessary.

*If the script returns output similar to the following:
WARNING: mixed source found...
WARNING: file(s) belonging to different PIs...
WARNING: file(s) belonging to different LOs...
 
-Contact Technical Support to obtain a healing scripts (hl_convert33.sql and hl_convert_gen.sql).
-Obtain a copy of a 2.0 200470 to 3.2 datecode dumpfile created after the Pro/CONVERT process was complete and prior to upgrading to 3.3. If the only backup available is a cold backup (only *.dbf and *.ctl files were backed up), contact Technical Support for assistance with restoring the database to a test machine and creating a dumpfile.
-Place the dumpfile in a path on the Dataserver.
-Execute the following from a command prompt/shell as an Administrator or Oracle user:

sqlplus system/manager
SQL> create user test identified by test;
SQL> grant resource to test;
SQL> grant connect to test;
SQL> exit
 
imp system/manager file=<path to dumpfile>dumpfile.dmp fromuser=pdm touser=test tables=pdm_productitemverfile, pdm_pivreplfile, pdm_lovfile, pdm_lovreplfile log=import.log

During import, the following Oracle errors may be returned and can be ignored:
IMP-00017: following statement failed with ORACLE error 942
IMP-00003: ORACLE error 942 encountered
ORA-00942: table or view does not exist
ORA-01917: user or role '<role_name>' does not exist

All other errors should be reported to Technical Support.

sqlplus test/test
SQL> grant all on pdm_productitemverfile to pdm;
SQL> grant all on pdm_pivreplfile to pdm;
SQL> grant all on pdm_lovfile to pdm;
SQL> grant all on pdm_lovreplfile to pdm;
SQL> exit

Change directories to the path containing the healing scripts
sqlplus system/manager @hl_convert33.sql test

During execution, the following Oracle error may be returned and can be ignored:
ORA-00942: table or view does not exist" for statement "drop table ..."

All other errors should be reported to Technical Support.

-Obtain a copy of convert_update2_33 utility and apply if a resolution to TANs 115838 and 113846 is desired.
-No further action is necessary.

Note: The convert_update2_32 and convert_update2_33 utilities can be found in the Downloadable Software Updates section of PTC's website under Pro/INTRALINK (http://www.ptc.com/cs/doc/prointralink31.htm). Contact Technical Support for any healing or detection scripts.

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hi Leute,

habŽda noch was:

Seht Euch mal die Varianten an! Auch wenn diese bereits eingecheckt sind, müssen sie nach einem CheckOut noch einmal aufgerufen und geprüft werden. Könnte ich mir in der neuen Logik recht gut vorstellen, weil das Datenbankfeld "geprüft?" ja noch nirgendwo einen Eintrag hat. Habe ich selbst noch nicht getestet, aber heute erfahren.

Was würde das heißen?
- Alle Generischen aufrufen, entweder durch die Kollegen im Projekt oder durch den Admin (ich weiß jetzt nicht, wer mehr zu bedauern wäre). Die Generischen Prüfen und wieder einchecken.
- Probleme bei den Berechtigungen, wenn die Varianten zwar verbaut werden dürfen, aber nicht geändert. Beispiel wäre ein zentraler Normteilordner oder freigegebene Objekte.
- Höhere Versionen, obwohl technisch nichts gemacht wurde. Könnte bei einigen Firmen zu Änderungsmitteilungen führen (wenn man es im dokumentationsrechtlichen Sinne richtig machen wollte), bloß weil die Version/Revision auf den Zeichnungen automatisch gezeigt wird.

Ich dence, das ich die schon oft angesetzten, und aufgrund der Projekte immer wieder verschobenen, Intensivtests der 3.3 in Kombination mit der Wildfire doch mal angehen sollte... wer weiß, was da noch auf uns lautert 

Viele Grüße

Detlef Bexkens

------------------

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP