Edit History

Submitted by sharon_jamieson on Fri, 2008-01-11 13:30.

Hiya. I would like to be able to have staff look for the edit history using a barcode. The problem is I want it to be the full edit history which of course uses ITEM_UPDATE table rather than ITEM. I have the sql for it and I can run it no problem but I don't know how to put this in to a script that would allow staff to enter the barcode number. I believe it isn't possible through Decisions. Any help from anyone that's done something similar would be gratefully received! Thanks. Sharon

Would you be able to get the

Would you be able to get the full history from ITEM_UPDATE? Don't you have to compress this table? Also, you only get a very select number of fields in ITEM_UPDATE - if someone edits a field that is not recorded, you'll see the fact that the item has been edited, but you won't know how.

Also, a colleague reminds me that some system jobs that amend items don't change the edit operator in the ITEM table. This means that the edit operator recorded in ITEM_UPDATE will sometimes not reflect who has made the edit.

Sorry that's a bit negative, but this is one area where the Talis system isn't designed to deliver information and it has frustrated us over the years.

Andy

----------
Andy Bussey
University of Sheffield

Edit history

As Andy said the ITEM_UPDATE table should be being compressed on a regular basis. I think we suggest monthly although this may be longer for various reasons.

The table was designed for picking up item changes for updating the OPAC and it is also used for producing updates for Talis Source etc. For those reasons you cannot be certain of having the required data and so no objects exist in Decisions for this table.

However as you said freehand SQL statements can be run in Talis Decisions in Desktop Intelligence only and it is possible to access the ITEM_UPDATE table in this way subject to the limitations in the table.

It is possible to include prompts in a piece of freehand SQL by using the @prompt function when creating the SQL statement.

The syntax of the @prompt function is

@Prompt('message','type',[lov],[MONO|MULTI],[FREE|CONSTRAINED])

In this example

select IU.ITEM_ID, IU.UPDATE_TYPE, IU.OLD_WORK_ID, IU.NEW_WORK_ID,
IU.OLD_ITEM_STATUS, IU.NEW_ITEM_STATUS, IU.BLCMP_UPDATE_TYPE,
IU.BLCMP_UPDATE_DATE, IU.CREATE_DATE, IU.CREATE_OP, IU.CREATE_LOC,
IU.EDIT_DATE, IU.EDIT_OP, IU.EDIT_LOC
from ITEM_UPDATE IU, ITEM I
where IU.ITEM_ID=I.ITEM_ID
and I.BARCODE = @prompt('Barcode?', 'A',, Mono, Free)

This statement will prompt you to enter an item barcode when refreshed and then return all the rows in the ITEM_UPDATE table for the item. You may wish to limit the attributes selected or insert additional conditions.

This will work even if the Desktop Intelligence report is exported to InfoView. It is unlikely to be possible to convert the Desktop Intelligence report to a Web Intelligence report with the Report Conversion Tool.

I will create an article that explains the @prompt syntax in more detail.

Brian Crampton
Developer, Talis

Thank you both for your

Thank you both for your comments. I'll try out the sql on Desktop Intelligence and see how I get on. I must admit I have never heard of the @prompt in sql (see how limited my knowledge is!) so some documentation on that would be very useful. Excuse my ignorance, but would that @prompt also work if the sql was put in to a script? Thanks again. Sharon

Using the @Prompt function

Just to clarify the @Prompt function is part of Talis Decisions and BusinessObjects. it is not an SQL statement. It just allows BusinessObjects to prompt the user and then the values returned are inserted into the SQL when the statement is run.

More information is now available in an article on the Decisions page

It is therefore not possible to use the @Prompt function outside of Decisions. If you want to pass values via the command line into a UNIX shell script then this can be done. There are details in the article Running SQL statements in a UNIX shell script.

It is also possible to insert values from user input into PERL scripts running SQL statements but I am guessing that wasn't the type of script you were referring to.

Thanks

Brian Crampton
Developer, Talis