Can CR write back to the dB 2

[thisisboni]

Hi,

I am 90% sure that CR cannot write back to the dB but I am hopinng that I am wrong !!!

If I run a report from CR - is there any way that I can write the results of the report generated back to the dB ?

I am on CR Enterprise 10 (running reports via CMC) and an Oracle 9i dB

Thanks
sam

 

[satinsilhouette]

Only if you write a script that can pick up a csv or text file and take the results and import it back into the db. Otherwise a crystal rpt cannot write back to a db.

Thanks so much!
satinsilhouette

 

[Turkbear]

Hi,
You can Export it to an ODBC DSN Datasource, but you need to be aware of the format rules of the target database...

We export to an Oracle database and use the imported table as a interim table for loading into other tables
( the format CR's export uses ( especially the field names )are not very useful as exported) -
we then drop that table, since the only option on Export is to create a new table.








To Paraphrase:"The Help you get is proportional to the Help you give.."

 

[synapsevampire]

Yes, set up an ODBC connection and you can write to a NEW table. You cannot append, insert or delete from existing tables, only create new tables.

Stating write back to a DB isn't very descriptive, please take the time to state what you intend, such as inserting to a table, etc.

You can alternatively use a COMMAND OBJECT or a STORED PROCEDURE, either of which can accomplish this.

A Command Object is a means to place real SQL in as a data source for the report, it's listed under your Oracle connection.

-k

 

[dgillz]

You can report on a stored procedure. The SP must have at least one select statement. But once Crystal runs the SP it will do anyting else that comes after that in the SP such as DELETE * from CustomerMaster.

You must be very, very careful here.

Bruce Ferguson and Ido Millet also have some insights on this I am sure.



Software Sales, Training, Implementation and Support for Macola, eSynergy, and Crystal Reports

http://www.gainfocus.biz

"A fine is a tax for doing wrong. A tax is a fine for doing well.
" - unknown

 

[IdoMillet]

Some 3rd-party Crystal tools (see list at:

http://www.kenhamady.com/bookmarks.html)

provide related functionality.

For a 1-page pdf file on how this is supported in my "Visual CUT" report manager, see:

http://www.milletsoftware.com/Download/Visual CUT ODBC Export Functionality.pdf

Also, my "CUT Light" UFL provides a function that allows you to use a Crystal formula to construct and execute an Update/Insert/Select stetment against any ODBC database (even if the database is not used as a data source in the report).

- Ido

view, e-mail, export, burst, distribute, and schedule Crystal Reports.

http://www.MilletSoftware.com

 

[thisisboni]

thanks for the reply all !

here is what I intend ! I am reporting off remedy data where by at the backend the data is converted (date as zulu time (epoch!!) , any drop down alpha numeric as numbers etc..) so I was thinking if via using remedy odbc I can run a report which converts these into proper format and once the report finished load the data into a 'NEW' table (which I can report off using native connection etc.!) ... sort-a like an ETL process.
The main purpose for this is Remedy ODBC though converts brilliant but cannot Join !! (I checked this with the bmc folks!)

tx folks
Sam

 

[BOjdh2n]

If you are using a version of Crystal Reports that support the "Command" style connection, then you can execute a Stored Procedure then Execute a Select Statement. I implement this process routinely to create what I call "Fly Marts" or to remedy situations where I run out of report passes.

Example:

EXEC SP_WHATEVER '{?Parameter}'

SELECT FIELD1, FIELD2
FROM TABLE WHATERVER
WHERE FIELD1 = {?Parameter}

The stored procedure is executed and the stored procedure parameter is satisfied by a Crystal Parameter (Typically a Date Parameter). The code in a stored procedure creates a temporary table in the DB that is then used in the preceding SELECT statement for what every purpose.