HomeSite MapCustomer Logon
 Dialog1
 DialogClassic
 DialogPRO
 DialogSelect
 DialogWeb
 ProQuest Dialog
Authoritative Answers for Professionals
Follow Dialog on Twitter  Follow Dialog on Facebook  Join Dialog on LinkedIn  You Tube e-Newsletters  RSS Feeds  Share

Support : Publications : Chronolog Archives : Sep/Oct 2002

Enhance Your Dialog AlertsSM with New Multiple Database Options

In July, Dialog introduced many powerful enhancements to the Alerts service. One of the most useful new features is the ability to set up a single Alert to run in several databases with the results pooled and, optionally, duplicates removed (i.e., "deduplication"). You may be considering consolidating your current Alerts into a single Alert, or expanding an Alert to scan additional databases. What are the benefits of running Alerts in multiple databases? When should Alerts running in separate databases be combined into a single Alert? How do you go about modifying an existing Alert to take advantage of the new functionality?

This document has been prepared to offer you guidance in

  • deciding whether to modify existing Alerts
  • choosing the best method for doing so
  • editing your current Alerts

Should I Set Up a New Alert to Run in Multiple Databases?

For most people, the purpose of an Alert is to scan a large volume of reliable information sources for documents of strategic interest. Broadening the scope to include additional sources contained in related databases is a smart way to make sure key data is not being overlooked. In today's global economy, for example, adding sources that offer extensive international coverage or that cover specific countries of interest makes good business sense. For example, if you are running an Alert in MEDLINE®, you can expand it to include EMBASE® and BIOSIS Previews® in order to obtain more comprehensive coverage of international biomedical journals.

The new Alerts deduplication feature can be applied to eliminate the same story appearing in multiple databases. Alerts are compared for duplicates within the same Alert and going back through up to twelve months of previous Alerts.

Should I Modify Existing Alerts to Run in Multiple Databases?

From a cost perspective, there is virtually no difference between "multifile" and "single file" Alerts. An Alert is charged for each database in which it runs. Alert costs remain the same regardless of whether you set up five separate "single file" Alerts to run in each of five databases or one "multifile" Alert that covers all five databases.

If you have the same or very similar search strategies running as Alerts in separate databases, it makes sense to combine them into one. Not only will you be able to take advantage of deduplication, but you will have just one "multifile" Alert to set up, edit and manage.

However, it makes more sense to keep Alerts running in a single database when they

  • involve unrelated topics
  • scan distinct types of content
  • make extensive use of indexing specific to an individual database
  • are delivered to different addresses

It is best not to "mix apples with oranges." For example, if you have an Alert running on competitors in an industry-news database and another in a patent database on a technology of interest, it is probably best to leave them as separate Alerts. It is certainly possible to combine them, but there is no cost advantage to do so, and it could be very confusing to manage if you have the results pooled in a single Alert. Similarly, if you have two Alerts running that go to different individuals, then it may be best to keep them separate for ease in tracking.

Many databases offer unique indexing that enables very precise retrieval; however, a very precise search strategy in one database may not work well in another. The use of different terminology and spelling, as well as the presence or absence of specific data elements, limits cross-file compatibility. This is especially true for searches involving the use of additional index fields or descriptor terms. For example, the major biomedical databases, MEDLINE, EMBASE and BIOSIS Previews, each use a different controlled vocabulary term for "gestational diabetes" (see "The FROM Qualifier"). If you already expended much effort crafting a model search to take advantage of a lot of database-specific indexing, it is best to leave it running in just that database.

How Do I Combine Separate Alerts Into a "Multifile" Alert?

There are several methods you can use to convert an existing Alert into a "multifile" Alert. They are:

  1. Modify your current Alert using the EDIT/SAVE ALERT commands (DialogClassic or DialogWeb)
  2. Recreate the Alert using the EXECUTE command with an existing Alert
  3. Modify your current Alert using the EDIT command
  4. Create a new Alert; delete the old Alert

Note that every Alert on Dialog is a saved search (SearchSave) with a unique name. The Alert name begins with a Dialog-assigned two-character code, followed by either the name you enter to SAVE the Alert or a number assigned by the system.

You can modify an Alert without incurring DialUnit charges by making your modifications while in a free database: Chronolog (File 410) or Bluesheets (File 415).

Getting Help

Help in modifying or creating Alerts is available from Dialog online, by e-mail, and by telephone.

  • Online help: support.dialog.com
  • United States and Canada: - 800 334 2564
  • Europe, Middle East, Africa: - 0800.690.000
  • Asia Pacific Region: - 1800 65 45 25 (Australia); 0800 44 17 73 44 (outside)

New Delivery Options

top

IN THIS ISSUE

Company Update
New on Dialog®
New on Dialog DataStar™
New on Dialog Profound®
New on Dialog OnDisc®
Tips and Techniques
Workshops, Seminars, Etc.
Chronolog Archives

  ProQuest   |   About Us   |   Site Search   |   Site Map  
Copyright Notices   |   Terms of Use   |   Privacy Statement