Are you searching for all records that have duplicate decision makers or are you wanting all records where the decision maker is a specific person?
This will be easier to do if you can merge your data into a single database instead of searching multiple databases. Is there a reason why you have multiple databases? (A more complete description of your data, tables and/or files will help us to help you.)
Thanks for your reply. well im using different databases for different clients. for eg: we ve different customers for Coke now several differerent companies might hv same decision makers like coke. so coke is 1 databse sony another one n so on i want to be able to search from all databases at once. is it possible? you said to merge the databses can i do tht how? pls let me know. thanks.
It can be done by searching all the tables for each file. But this isnt exactly novice material to get the results back in one spot.
Perhaps you coule benefit from this product which makes it a lot easier to integrate.
* Edit - reworded
You haven't answered my first question yet...
But to merge your databases, You need to make sure your tables have a field that uniquely identifies each company. Then you can simply import the records from one database into another. To see just the data for a given company, you can perform a find for just that company.
The exact details depend on the structure of your database but it sounds like you should have several tables for this--not one table for each company but instead one table for companies, another for "decision makers" and so forth...
im gonna search for a specific decision maker so i want it to search in all databses and return the records with tht decision maker from all databses or whichever database it is found in
If you can get all your decision maker records into one table, you can simply perform a find on that one table. Otherwise, you have to use more cumbersome and complex approaches. You may also find you have the same decision maker recorded in two databases with just enough difference in how you've entered their information that your search might fail to find them.
You could, for example, perform the same find on each database and capture the serial numbers of each found record. This information could then be copied back to a central file where a portal to each database uses this list of serial numbers to display the records found in each database. That's not a simple thing to set up and merging your data makes it unnecessary.
I would also like to perform searches (using script language) in different external archives from "my" archive. I have no possibility to megre the archices. Could anyone explain please!!!
It's not a simple process and there are a lot of issues to resolve.
Do all your records have unique serial numbers?
What kind of search? Just one value in one field?
Need to use special operators?
Complex finds needing multiple requests?
This is one of the few cases where you still end up copying to and from the clipboard.
Create a layout in the external file where the only field present is the serial number field.
Let's say you need to find all records in your external file that contain a word starting with "Apple" in a field called name.
From your original file, call a search script in your external file, passing "Apple" as the script parameter.
In the other file your script might look like this:
Go To Layout [SerialNumbers (Your Table)]
Enter Find Mode
Set Field [YourTable::Name ; Get ( ScriptParameter ) ]
Set Error Capture [on]
Perform Find 
If [ Get ( FoundCount ) > 0 /* records were found */]
Copy All Records
#Make sure that the clipboard is empty by copying a space character from a field and layout set up for this purpose
Go to Layout [UtilityLayout]
Now back in your original script the next line after the Perform Script call triggers the above script.
Go To Layout [//Layout where you have a text field to paste your list of records]
Now if you have a relationship linking YourRecordListField to the serialnumber field in the external file, a portal to the external file based on this relationship will list all the matching records.
A simpler approach might be just to define a temporary reporting table and import copies of all the matching records from the find on each table into this table. A report layout based on this table can be used to display your results without copying serial numbers.