Λύθηκε !!!.
Ύστερα από αρκετές ώρες "Σερλοκχολμικής" αναζήτησης η απάντηση πιστεύω ότι βρέθηκε...
ΣΗΜΑΝΤΙΚΟΤΑΤΟ: Πριν από όλα μερικές διευκρινήσεις: Όλα τα πειράματα έγιναν σε νέα, τελείως καθαρή εγκατάσταση σε Virtual Machine, που είχε WinXP Eng SP2, VS2003*, SQL 2000 Dev, .NET Framework 1.1, που ανά περίπτωση είχε:
Α. Τίποτε άλλο. (Τα reports κατασκευάστηκαν με το VS Embedded Crystal Report)
B. Crystal Reports 9.0 Pro
C. Crystal Reports 10.0 Dev
D. Crystal Reports 11.0 Dev
* Επίσης το μηχάνημα του development είχε εγκατεστημένο μόνο το CR του Visual Studio (v.9) και τα CR βρίσκονταν εγκατεστημένα σε διαφορετικά μηχανήματα χωρίς VS.
Φυσικά όλες οι εγκαταστάσεις περιλάμβαναν όλα τα Service Packs, patches και λοιπά απαραίτητα εγκατεστημένα.
Η όλη ιδέα ήταν να κατασκευαστούν reports που χρησιμοποιώντας την λογική του .ttx (Field Definition File) θα περιείχαν μόνο το layout του report. Κατά τη φάση του runtime της Χ. εφαρμογής μας, τα reports αυτά, αφού τροφοδοτούνταν με ένα οποιοδήποτε Dataset είχε το ίδιο 'σχήμα' με αυτό που περιγράφονταν στο .ttx αρχείο ...rptDoc.SetDataSource(dt); θα πρόβαλαν τα δεδομένα.
Επειδή λοιπόν σε πραγματικές συνθήκες, τα reports θα φτιάχνονταν από κάποιον που θα δούλευε το κανονικό Crystal και όχι την VS embedded έκδοσή του π.χ. κάποιος παραμετροποιητής, θέλησα να προσομοιώσω την διαδικασία κατασκευής και εκτέλεσης ώστε να είμαι σίγουρος για το αποτέλεσμα. Κατασκευάστηκε ως εκ τούτου ένα rpt, σε άλλο μηχάνημα (εξομοιώνοντας με αυτό τον τρόπο την κατασκευή του report από τον x χρήστη μη προγραμματιστή), με CR9 Pro, τοποθετήθηκε σε κάποιο folder και στην εφαρμογή μας φορτώθηκε κατά το runtime με:
rptDoc.Load("???.rpt");
rptDoc.SetDataSource(dt);
rReportViewer.ReportSource = rptDoc;
Το αποτέλεσμα ήταν να μην βλέπουμε data, για την ακρίβεια όπως διαπιστώσαμε, βλέπαμε τα όποια data χρησιμοποιήθηκαν κατά την κατασκευή του rpt. Αυτό έγινε χρησιμοποιώντας την δυνατότητα του .ttx να ορίζει εκτός του σχήματος και sample δεδομένα ώστε να είναι ορατά κάποια βοηθητικά data κατά τη φάση του design του report, π.χ.:
;Field definition file for SalesPayWay
SalesManID Short 999
SalesmanCode string 10 TestValue
Ουσιαστικά με αυτό τον τρόπο κατάλήξαμε ότι αυτό που δεν δουεύει σωστά είναι η
SetDataSource.
Μελετώντας το πρόβλημα προσεκτικότερα, ανακαλύπτουμε ότι το rpt συμπεριφέρεται τελικά με τον ίδιο τρόπο άσχετα με το αν κατασκευαστεί με CR9Pro, 10Dev (eval.version), ή 11Dev, αυτές διαθέταμε…, αρκεί να γίνουν τα ακόλουθα:
1. Το Rpt κατασκευάζεται σε μηχάνημα άλλο από το development.
2. Το Rpt αντιγράφεται και εκτελείται στο μηχάνημα runtime όπου βρίσκεται εγκατεστημένη η εφαρμογή μας, compiled και packed για Setup από το VS, που όπως θυμίζω έχει εγκατεστημένη μόνο την embedded έκδοση του VS (v.9.0). Κατά συνέπεια, πολύ μεταγενέστερη διαπίστωση, και τα .msm (Merge Modules) είναι αυτής της έκδοσης.
Προβληματισμένοι από την παραπάνω συμπεριφορά, δοκιμάζουμε αφού είχαμε ήδη προσπαθήσει με αποτυχία τη μάλλον άκομψη απλή αντιγραφή των CR11 .dll's στο execution path του target μηχανήματος, να κατασκευάσουμε το Setup project, χρησιμοποιώντας τα .msm του CR11. Φυσικά στην όλη διαδικασία ζητείται και το Keycode των CR.

Με αυτό τον τρόπο κατασκευάζουμε ένα Setup το οποίο registrάρει (γλωσσοπλάστη μου …) σωστά την εφαρμογή μας ώστε να φορτώνει rpts που κατασκευάστηκαν με άλλη έκδοση από αυτή της embedded έκδοσης του VS. Αυτό εξηγεί και το γιατί η εφαρμογή αρχικά δεν είχε πρόβλημα να παίξει με τα reports που φτιάχνονταν με την embedded έκδοση, καθώς το αρχικό packaging του setup είχε γίνει με τα msm που αντιστοιχούν σε αυτή την έκδοση.
Θα ήθελα επίσης να πω και ένα ευχαριστώ στον συνάδελφο Πάνο, (axaros) που ουσιαστικά με οδήγησε σε κάποια από τα παραπάνω συμπεράσματα. Ακόμα δίνοντας μου την αρχική ιδέα για .xml τελικά τροποποίησα την λογική της τήρησης του άνευ data σχήματος από .ttx σε .xml πράγμα που αφενός διόλου δεν αλλάζει την λογική κατασκευής του RPT απλά χρησιμοποιώ New Connection -> DataBaseFiles -> .xml … αντί New Connection -> Field Definition Files -> .ttx και επιπλέον παράγεται αυτόματα με:
private void WriteSchemaWithXmlTextWriter(DataSet thisDataSet)
{
System.IO.FileStream myFileStream = new System.IO.FileStream(xmlfilename,System.IO.FileMode.Create);
System.Xml.XmlTextWriter MyXmlTextWriter = new System.Xml.XmlTextWriter(myFileStream, System.Text.Encoding.Unicode);
thisDataSet.WriteXmlSchema(MyXmlTextWriter );
MyXmlTextWriter.Close();
}
Αυτά τα ολίγα (καλά μην βαράτε) μήπως και κανείς άλλος χάσει τον ύπνο του με το ίδιο ...
Καλό κώδικα...
Debug macht frei.