custom reports and 5.0

[Guest]

hopefully you won't have as much 'fun' as I have had trying to get your reports set up for conversion to 5.0.

anyway, this is the scoop from the National Council Meeting just held:

ALL custom reports must be modified to Oracle. This is true whether you have been running Gupta or Oracle! ALL custom reports have 'remnants' of Gupta, simply because of the way the system works. Surprise, surprise.

At the meeting it was strongly recommended that you modify the reports before converting to 5.0. In fact, the term 'MUST' was used, although by the close of the meeting, it was stated that there might be a way to do this process after converting - a method was being tested.

all that being said, converting has been anything but easy - from my point of view. Lack of adequate documentation.

1. you may have to edit your ODBC and ODBCINST to remark out references to Gupta.

2. there is a 4 page step by step walk through of modifying custom reports available. obtain this from Quantechland.

3. make sure while modifying your reports you either save under a different folder or under a different name. speaking from experience I have modified some reports that can no longer be opened. Thank goodness I renamed the originals.

4. Most of my SQL Tables after conversion end up simply as (example) PLANEE, but a few end up as SYSADMIN.PLANSTAT

The original instructions I was given was to set the location on PLANSTAT a second time to get rid of the SYSADMIN

If I DON'T do that, my report is still useable at 4.1 If I reset the location for PLANSTAT I can no longer use that report.

and all this before converting to 5.0! I have sent a few reports to Quantechland for them to try at 5.0 before I go further, so that is the best I can tell you at this time. Hopefully more information shortly.

At 5.0, a number of tables have been eliminated, and new tables created. This means you will have further adjustments to be made to the reports at 5.0. The original documentation was not the greatest - there should be some better documentation available soon from Quantech.

(Your National Council Members at work for you!)

my apologies if I have left something out!

[Guest DottleC]

I wonder, is Quantech making this documentation for converting reports available, or do we have to convert to QT 5.0 first? Does the new version (6.0) of Crystal have to be modified any differently than the old 4.x? Will we know which tables are changed, and which remain the same?

[Guest]

There is some new documentation available about how you should make sure all reports were 'oracle' before going to 5.0. I have not heard if they figured a way to do things at 5.0. Supposedly they were testing this.

Yes, a number of tables were dropped, and new ones added. Particularly dealing with vesting. I have found the new 'vest' code in the table, but have no clue how to distinguish 'match' from 'profit sharing'.

The user definable elements also have me baffled at the moment. For example, you use to have PLANSTAT.USERNUMBER2, now all I find is PLANUDF.USERNUMBER (I think that is how it is labeled, but I don't have Quantech open at this point - we only loaded one machine so far, and each machine has to be loaded) Anyway, I have no clue how to tell the system which USERNUMBER field I want, so I have a request in for that information.

Anyway, hope to have more information available later today.

[FAPInJax]

Some comments regarding the Crystal conversion.

It is strongly advised that all reports be set to the ODBC-CROR7 server type BEFORE going to QT 5.0. This is because QT 5.0 is strictly an Oracle application. It also makes the updating of the custom reports easier and could save time (depending on how adverse you are in Crystal).

Documentation has been modified. It is no longer in paragraph format but steps. This should be much easier to read and follow. Conversion of reports will depend on the how adverse the user is with Crystal.

Once the conversion is accomplished you WILL have to adjust your ODBC.ini and ODBCINST.ini files to reflect Oracle. Please feel free to call Report Writer support to assist you with this. (When you are in Crystal and try to set your reports to Oracle - you should get a prompt as to what source to use - IF you do NOT get this then your fields need to be changed!)

Having a backup of your custom reports is ALWAYS advisable before conversion (for example, you may have too many report tables in your custom report and some may get lost, you may need to adjust the number of tables and possibly get rid of tables that are not actually being used - an example of the latter that we see all the time is the PLANDYN table)

IF your tables showed SYSADMIN in front of the table name - it would have been there before converting! This happens based on Crystal settings. (Crystal can NOT change the type of table without being told what to do)

Following all the steps should save you time in the long run BECAUSE you can do a few at at time and NOT have downtime at 4.1.

Some tables and fields have been deleted. The documentation includes a list of these tables and fields. Therefore, you should be able to verify IF any reports have these tables or fields and adjust them when updating to the new version.

The report conversion documentation will be available on the Quantech FTP site.

[Guest]

Hopefully the following will be in the revised documentation:

1. Something to indicate to the users that the ODBC files may need to be edited. Perhaps even what to look for as it may save a call or two. Why tell someone "After loading the update, you will have to call support to find out ODBC adjustments"

2. Instructions on using the user defined fields. All the old documentation says is that the old format will work at 5.0, but update as soon as possible. Nothing to indicate how to do this.

In the past you chose PLANSTAT.USERNUMBER7

and it worked.

Based on the info I received from support you now need to write a formula

if {PLANUDF.UDFROWNUM} = 7 then {PLANUDF.NUMDATA}

I would say that is a pretty significant change. I certainly wouldn't have had a clue how to pull the user fields.

[Guest JohnB10]

Great topic! I think I'll add another week to my conversion schedule. :-)

A few additional comments.

If you use compiled reports, you'll need to re-compile them prior to use (and after pointing to CROR7).

Is anyone running or planning to run Crystal Reports off a network drive? The default QT 5.0 upgrade instructions put it on the hard drive, but they also say you "can" run it from a network drive.

Is anyone using another application that uses Crystal Reports? If so, have you seen any problems when loading or using the QT Crystal?

Thanks!

John P. Bronikowski

Emjay Corp. - A Wells Fargo Company

Any opinions herein are my own and not necessarily those of Wells Fargo.

[Guest Sherry Gantwerker]

This is in response to a question regarding problems with other software using Crystal. YES!YES!YES! We recently had an upgrade to a timekeeping software called CPASoftware (we are a CPA firm that also does TPA work). Unknowing that this software uses Crystal, we opened the new version of CPASoftware & all of our Crystal Reportwriter reports went bonkers! Wrong data, messed up tables, etc. We couldn't use ANY report using Crystal. It appeared that the CPASoftware upgrade had newer Crystal report file dates and overwrote those in QT (that had older dates). I later found out that Corbel pays Crystal to modify its standard versions to work better with Reportwriter. So, when Crystal 6.0 is bundled w/QT 5.0 it will not be the regular 6.0 (that may be bundled with other software on your network). We can't even have the software on our own harddrives because as soon as it is accessed, it overwrites QT Crystal. Those who use QT have to do manual or Excel timesheets that are then keyed into the CPASoftware module on other PCs.

[FAPInJax]

There appears to be a LARGE misunderstanding.

Corbel has NOT paid Crystal to do anything to it's software. Any modifications that appear in the functionality of Crystal are theirs alone.

We are aware that other software also uses Crystal and users should be aware that there may be differences in version numbers.