We have report and users want to upload filters to prompts on the reports from excel or csv files. They cannot enter one by one because they sometimes have hundreds of values (customer numbers) to filter. Is there a way to do that? If it is then how is it possible?
Thanks in Advance.
Niki
I'm assuming you're using either Web Intelligence or a different document format that is supported by the OpenDocument feature.
One possibility is to use an Excel file with a column for each prompt value. Use this Excel file as a source for a new Web Intelligence document. Within that document, construct OpenDocument URLs that contains the prompt values you want to pass.
Make sure that you read the OpenDocument manual carefully, as the syntax for passing prompt values differs depending on how the prompt is configured (single value vs. multiple values, etc).
The idea behind this is that you have an easy to maintain Excel file to input/modify the prompt values, and that end-users can open the intermediate Web Intelligence document, refresh it (or use refresh on open) and then click one of the generated links to automatically open the correct document and have all the prompt values filled in.
Example
Consider the screenshot below. It's an Excel file that contains information regarding two documents (Dummy Report and Other Report) as well as their internal ID (CUID) and the prompt values to refresh them with.
This is sufficient information to generate an OpenDocument URL to open these documents for us and automatically enter the prompt values.
The resulting URLs would look like this:
http://<servername>:<port>/BOE/OpenDocument/opendoc/openDocument.jsp?iDocID=Aa6GrrM79cRAmaOSMGoadKI&sIDType=CUID&lsSYear=2015&lsSMonth=2
http://<servername>:<port>/BOE/OpenDocument/opendoc/openDocument.jsp?iDocID=Aa6GrrM79cRAmaOSMGoadKI&sIDType=CUID&lsSYear=2015&lsSMonth=2&lsSCity=Berlin
Some remarks here:
If your documents have different prompts (e.g. City is a prompt in the second document but not in the first), or some of the prompts are optional, you'll have to check for which columns (prompts) a value has been provided in the Excel sheet and discard the empty ones (should be easy enough).
Unless Single Sign-On (SSO) has been configured in your BusinessObjects environment, you'll still have to log on.
Due to this approach, you can make prompt values dynamic (e.g. use the current year) by using Excel formulas.
The example above is a very simple one. You could have multiple lines referring to the same document but with different prompt values.
Taking it one step further
If you use this Excel sheet as a data source for a Web Intelligence document, you can create a Webi document that contains the OpenDocument links. The added bonus is that you won't have to log on anymore after clicking one of the links, as you're already working in an authenticated session.
Important
Make sure you read the OpenDocument manual carefully so you understand what it is and how it can be used (and more importantly, what you can't do with it). You can find the manual on help.sap.com. Just make sure the version described in the manual corresponds with the version of BusinessObjects deployed in your environment.
Not currently possible. What we did for this requirement was to create a new dedicated table in our database to hold customer-generated prompt values. We then created a simple web page to allow users to upload lists of values. Finally, we created universe objects that associate the customers' LOV table with existing universe objects as filters.
Related
I am trying to use metadata from an Excel file to use for filtering in our sharepoint libraby.
The excel file already contains dropdown menus to pick certain values from, which are then used to create a very lengthy filename. However for our new sharepoint libraby I would like to move those to metadata, so it can be made visible in sharepoint columns and users can filter.
The file is a template that should be filled by users and when ready saved after choosing certain values.
The creation of the filename is done in VBA and therefore all values I want to use are available there.
I've tried a number of approaches I found in forums using e.g. customdocumentproperties and made it work...sometimes... While it worked in the beginning, I cannot make it work now.
It seems changing the metadata is a problem. Creating the metadata fields for the first time worked, but then changing it, did not. I have the feeling I do not understand some basics on this action. Microsoft websites are not of any help here...
What is the best - flawless - way to use VBA to create, add, change metadata in the excel-file that can be made visiblle in the sharepoint library? And are there any typical problems?
We are using a access front end that is being developed externally. It displays a form that contains numerous points of data and a few subforms.
I am trying to code a excel sheet that would pull data from various places in the currently open form.
I have gotten as far as to be able to access all the points of data in the main form and the first line in the subforms using the following code (In this example, the "pnum", is the left most field displayed in the subform):
Set objacc = GetObject("xxxxx\Database.accdb").Application
Debug.Print objacc.Forms("mainform").Controls("main subform").Controls("Pnumber")
This works and gets me the value of the very first element named "Pnumber" in the main subform.
However, the way the subform is formulated, it can have anywhere between 1 and 30+ "Pnumber" fields.
I need a way to pull everything that the currently visible (filtered down) subform contains regardless of how many lines there are.
Thanks!
If I were the developer of that Access application, and you asked me for this feature, I would code an API for you to automate getting the right data.
One approach I can think of in this particular case would be to populate some temporary tables, on request from Excel VBA, and have Excel use the Access database file as an external source of data. Or Access could be coded to push the right data into the open Excel worksheet.
The way you would get access to the data in its current state in the form (filtered, sorted, etc.) would probably be best through the RecordsetClone property of that (sub)form. At least that's what I imagine I would use to implement that feature.
In my Access 2013 Desktop database, I want to validate an Excel form through VBA before importing its rows to a table.
The problem is that the imported Excel table may contain in the same column values that are numeric, string, null, etc. depending on the row due to mistakes from the user, so these values have to be initially of VBA type Variant before validation.
If the row is invalid (e.g. one value is not of numeric type while it should be, one mandatory field is null, etc.), I want to be able to store its values and let the user correct it later on. I am therefore looking for a way to build a table where I could store these rows, but where the fields are kept intact, so with the possible mixed data types.
This seems not to be possible, as Access tables need apparently to have fields of a defined type, so nothing equivalent to Variant.
How could I achieve this? What would be the simplest and most efficient way to store rows of Variant values while keeping the structure of the columns? The only way I could think of so far is to concatenate these values for each row in a string using some defined separator, and store this in a String column in an Access table, but maybe there is an easier way to do?
Thanks a lot for your help.
EDIT: Reading your answers I realized that I forgot to specify that the people filling and sending the Excel forms (who typically do not have Access on their computers) are not the same users than the ones who have the Access database and need to import the data. In this configuration it is impossible to use directly Access forms to input data, which would of course simplify tremendously the task. While we try to enforce rules for people who fill the Excel form at the first place there will be mistakes and the Access application needs to cope with them. And the importing process for the users manipulating Access should be as simple as possible (these users are not experts in IT).
I though about your problem for a while and made a few notes as I thought below.
I would strongly advise that unless the excel workbook is providing other functionality that you do not use excel, but create an simple Access database with a form they can use to interact with "their" data. They do not necessarily need an Access license to do this. Access 2013 even has new web features that can be used if you have sharepoint to collect data via a Access created web frontend.
If you are to collect data in Excel, then you must use excel validation and VBA code to validate the data as much as possible before transferring to access.
There are complexities that may or may not be an issue for you, things like:
Can users edit/created/delete the same rows concurrently - what happens if they do! You may need to "lock" rows when they are downloaded from Access. But what happens if tow users add the same record, or ones deletes a row before another user commits it back again.
Can a user open multiple excel files and edit the data they store without committing the data to Access?
Can multiple users login to the same Workbook with uncommitted changes and edit the data.
Using access will simplify your code as it will be able to prevent erroneous data being entered and remove the need to deal with the above issues and others
In summary you are using excel as a front end "form" to data stored in Access.
Each excel file can have data that has yet to be up
I would suggest that the primary key of a row is the "path and name" of the excel file that was used to create it & a unique numeric identifier. The unique identifier is a counter that is maintained for each excel file. The "path and filename" could be replaced by a unique identifier created for each file.
Many users enter data using multiple instances of Excel into a form which results in one or more rows being updated/inserted/deleted in an Excel table stored in each spreadsheet.
I would expect that whenever Excel is opened the user enters a username and excel will grab "their data" from Access. Alternatively a workbook might be set up for each department or "case type" and only interact with data that matches this "custom criteria set up in the workbook". Excel would not necessarily need to store data itself longterm. The workbook might always save data back to the database when it is saved.
You say Excel VBA performs limited validation on the data (but no complete validation). It should be used as much as possible and arguably should be able to do exactly the same validation that access can do. At the very least it should enforce datatypes etc (eg using the standard data validation rules on the excel data menu) or perhaps use VBA/controls to get any access data it needs to validate the data entered.
After updating the data the user can "commit" (ie save) the data to the access database. Before closing the workbook you might want to commit the data.
(An issue is whether a user might open many workbooks perhaps on many machines without committing the data.)
An Access "staging" table can be created with all columns having the datatype "shorttext" and not-required.
The process that loads data from an excel table into Access, will uploaded all excel rows into this staging table. It will then validate each row in the staging table and process all valid data into the main table(s) that have data types, relationships constraints etc.. Any valid rows in the staging table are flagged as "VALIDATED & TRANSFERRED", Invalid rows are flagged as INVALID. The "VALIDATED AND TRANSFERRED ROWS" are subsequently ignored, but kept so you can check what processing has happened, perhaps only whilst testing.
The data in excel is then updated with the Valid/Invalid status from Access and suitable messages given to the excel user. The user may correct and then re-commit the data.
Each excel file has a status of "changed/Unchanged" to indicate whether a user has changed data in the file.
When a user opens an excel workbook and status is unchanged it will refresh it's data. If it's changed a refresh probably can't be done.
In order for the data in Access to be updated/deleted/inserted with the changes made in Excel, there will need to be a unique identifier for each row that cannot be changed by the users in excel. This is likely to be the Path&Filename or the UserName logged into Excel and a numeric counter (which is maintained for each file or user). (This assumes that the user will have to commit changes in one excel file before they work on another.)
Anyway, without knowing more it's difficult to fully design what you will need, but I hope these thoughts help you
Harvey
I have a project in Access where we are using tables that have the customers information. These tables were created by downloading as Excel from another site of ours and then uploading to the Access program.
The problem is that the information on our other site changes sometimes, and we really don't know what has changed on our existing information. When we append a new Excel download it will add customeraccountID's that are not on the table yet, but I need a way of finding out if there are any changes to the existing information.
I have tried an update query, but that makes forms that have a relationship to the customer information tables not show the detail section. From what I have researched, this is possibly due to the update query making the updated table read only.
I have taken an made a query that gives me a list of all the duplicates between the newly downloaded Excel and the existing table, but now I need some way to find if there is any changes. There are 60 columns where there could be changes.
We are not against manually updated our tables if we can find a way of finding out what has changed.
I have considered downloading the duplicates report to excel and running a formula using exact(a2:a61,b2:b61), but then I would have to copy that formula to every other row through thousands of rows. I have no preference to whether we find the changes by Excel or Access.
The best way would be to have Access replace the information when appending the new information, not just drop the duplicates. Which would mean having Access replace the existing data when appending. Is that possible or can a report be created that shows where the information differs?
I want to update all User information as per given in Excel file and excel file contain more that 500 user information
I am trying to write down the script that Read Excel File , get a data for Searching and than find the object in Active Directory. For Eg.
Suppose I have Excel File Name as All_Users_List.xls
And that file there are information about all users information and there title and manger information
FirstName LastName title EmailAddress Phone ManageFirstName ManagerLastName
VBScript open a file and read a data from each row and Search for user Who's First Name and Last name Match then bind it to modify and update the information given in Excel file. If it find more than one user it should show all users who's First and last Name are same with additional information like Description and ask for input and if no user and manager found in Active Directory it should mark the Row with Red color for manually work latter for searching or identifing which user is not update as per the excel file.
Assuming that you have Excel installed on the machine where this is running you can get out the information from the Excel file using automation. See this article for further information on how to do this: How to automate Excel from a client-side VBScript
To read/write the value from a cell, use something like wb.Activesheet.Range("A1").Value.
This old SO question should give you a starting point for the AD stuff: Querying Active Directory using VBScript
Please note, automating Excel is not supported on a server, so this solution is probably only suitable if you're going to run this code on a client machine rather than some kind of server. Otherwise you should probably look at ADO rather than Automation (this might also be better if you have a lot of date since it can be a little slow to read/write a lot of records via automation).