If you have a list with a People/Group data type that allows multiple selections, the data you get in an Excel export is a bit dodgy.
Example:
Instructors:
Berry, Patrick;#10;Smith, John;#136
Is this just something I need to deal with in Excel, because it makes reporting based on people filtering somewhat challenging.
Excel would be the best place to deal with it. The formatting is a part of how SharePoint store the data in the underlying field.
The field is formatted #[list item id]; [list item name]; where the id comes from the Site collections list of users.
The issue with reporting is that you would probably want a separate line for each user in order to use any of the pivot functions in excel. This would be an exercise in VBA manipulations of the data.
Excel does allow the referencing the Microsoft VBScrip Regular Expressions 5.5 and a the regular expression #\d+;? should find the different values.
Related
I currently have an Excel file with a data entry form- a formatted sheet with vba to provide combo boxes, validate data types & form completeness, and then load the entered data to another sheet. I'd like to put this on Sharepoint for my team to use, but Sharepoint disables VBA. I'd prefer that they be able to enter data online rather than downloading the Excel file and re-uploading. Any advice on how to do this? It's preferred if I don't have to start from scratch, but suggestions on the easiest way to implement this are also welcome.
Specifically, this is a savings tracker for a procurement group. I'd like my team members to individually be able to enter negotiation data once complete: project name, supplier, baseline costs, negotiated value, effective date, etc. Some fields have a list of allowed inputs- most are short lists, but the supplier list is quite long. Their data would then be stored in a single table that I can build reports with in Power BI. My team is not particularly tech-savvy.
Thanks!
Like the title says is it possible?
I need a table in my exported excel sheet that will be used with data validation setting.
If you referring to Excel Tables (i.e., Excel's Ribbon > Home > Styles > Format as Table...), these objects are not supported by SpreadsheetGear, so adding such tables would not be supported, either. For existing workbooks that contain Excel Tables and are opened in SpreadsheetGear, the Tables feature will get dropped upon opening, which is worth noting that, in addition to formatting being dropped, any "structured references" will be converted to "#REF!" errors. An alternative to using structured references would be Defined Names, which are very well supported by SpreadsheetGear.
I work for SpreadsheetGear, and we do keep track of customer requests for things like this. So you are welcome to contact us directly at support#spreadsheetgear.com if you would like us to add your contact details to this particular feature request, though I cannot say when we might add Tables to our product.
I am creating a tracking document for artists' accommodation as part of an arts festival and would like to automate part of my work flow. Whilst we use event management/scheduling software for confirmed bookings, it's nice to do all my working in Excel.
I would like to have a master sheet (sheet 1), with a full list of artists and their respective accommodation - that can then be sorted into individual sheets (sheet 2, 3 etc) based on the name of the accommodation. The automatic sorting would also capture the other pieces of information in the row.
This would allow for each different sheet to show a report on who is staying in each type of accommodation and would be rather handy!
I would recommend one or more PivotTables as a simpler solution. Here a PT and two clones are shown on your Master Sheet, but they could each be on their own sheet:
Accom is in Report Filter, Company is in Row Labels and PAX (as Sum) is in Σ Values. Once having clicked on PivotTable in Insert > Tables - PivotTable and having chosen you range ('Master Sheet'!$A$2:$C$7A2:C7) and Location just drag the fields from the big box to the little ones.
This is feasible using Excel, but I don't recommend it; it is creating a maintenance nightmare in the long run.
From the question I can't gather whether the data is available in some kind of event management software package; if so you can use that one as a data source. Or create an Access or SQL database with a few tables. After that, you can use one of the following options to make the necessary overviews and as many more as you think up during the project:
Use Excel with ODBC or web query to retrieve data aggregated and
sorted as you like. Make changes in the event management package
allowing others to see the same facts. Or do it in Access. When you
change one thing, it automatically propogates also into the Excel.
Similarly, you can use an Excel add-in such as Invantive
Control (caution I work at a supplier) to retrieve the data from
the database using SQL or a webservice, change it from within Excel and
then synchronize the changes back assuming you have write access.
A similar solution is available as SQL*XL. Probably there are others too.
If the solution must be Excel only, I would recommend using vertical/horizontal lookups with the Excel function vlookup / hlookup (Dutch: vert.zoeken, horiz.zoeken). These function perform reasonable with a small amount of data and performance can be improved by sorting. And they resemble SQL joins, so the database you get within Excel more easily conforms to the relational model.
I hope the event is successfull and the people enjoy it.
I have an Excel table with data but here the rows and columns each have meaning, for example:
ColHead1 ColHead2 ColHead3
RowHead1 Data11 Data12 Data13
RowHead2 Data21 etc. etc.
RowHead3
I would like users to edit the data using SharePoint forms.
I've considered the following options
Flatten the data and manually add editors for each field onto the form (so that I can simulate some sort of grid layout). This may become unmanageable if I need to make a change though.
Insert the data into a list and let SharePoint create a default form, but this will also flatten the data.
Is it possible to somehow use the data in SharePoint directly in a List (or lists) without flattening?
Or should I just post the Excel sheets for direct editing in SharePoint?
You are right. 2-D data cannot be handled by SharePoint.
The best solution here would be to use Excel Services.
In 2007, Excel Services did not allow to write changes to backend file. I am not sure if the situation has changed with SharePoint 2010. You might have to check it out.
You can also put Excel file in document library itself.
However, what I am missing here are the business objectives for this requirement. What essentially do you want to achieve by putting this data in SharePoint forms ? May be there is some better way which others will be able to suggest if they know actual requirements.
My Access programming is a little rusty, & I've never worked with Excel files all that much.
I have a requirement to bring data from Excel spreadsheets into Access 2007. These spreadsheets have a fixed (predictable) format, but it includes a "header area" where I need to read single data items from specific cells, followed by a mass of tabular data (~500 rows in the one sample I've seen so far). I will be processing all of this into a set of tables that are normalized quite differently from the flat layout of the spreadsheet.
I know how to open an ADO recordset on the tabular data, and it should work fairly well for my purposes. I also figure that I can reference the Excel object model and open the sheets through Automation to get the "header area" data items.
My question is this: since I have to (I think) use the Automation approach for the "header area", am I better off just leaving it open in this mode to move on to the tabular data (with cell/range navigation), or closing that mode & going over to ADO? I suspect it's the latter--and I'd be more comfortable with it--but I don't want to do the wrong thing just because it's more familiar.
Edit
It seems I wasn't clear that I need to build this capability into the "application", as something that a user can repeat down the line. I'm assured that I can trust the format of the spreadsheet (though I'll include error trapping for graceful failure if that turns out to be false). These spreadsheets are "official design documents" for hardware, and my app needs to handle bringing in new &/or updated ones to track the things that are described in the tabular data in ways that the flat Excel format diesn't allow for.
Of those two options, I would choose the second simply because I find it more convenient to work with an ADO recordset. It should be fairly simple if you can assign a named range to your spreadsheet's tabular data.
Edit: If your spreadsheet includes field names, the recordset approach would be less prone to break due to spreadsheet changes such as one or more new columns inserted before or between the existing columns or a re-ordering of the existing columns.
But actually, I think the TransferSpreadsheet Method might be more convenient. You can specify the spreadsheet range as a named range or by cell address as in this example from the linked page:
DoCmd.TransferSpreadsheet acImport, 3, _
"Employees","C:\Lotus\Newemps.wk3", True, "A1:G12"
Also, you can choose between importing the spreadsheet range directly into an Access table, or linking to the range as a "virtual" table ... whichever best meets your application's needs.
Edit2: Creating a link (acLink instead of acImport) with TransferSpreadsheet would allow you to execute SQL statements against the link table:
INSERT INTO DestinationTable (field1, field2, field3)
SELECT foo, bar, bat FROM LinkedTable;
If the header information is really complicated, this can simplify your coding work:
In the official design Excel file, create a hidden tab.
In that tab, make a 1-row table connecting to all the header elements you're interested in. (i.e. set row 1 column 1 to "Document#" and row 2 column 1 to Sheet1:A1)
Then you can re-use the same VBA procedure to import both your tabular data and your header data.
I would do it all via Automation. Why have two separate processes where one will do? After you've read the header information reading the tabular information will be quite easy.
I inherited an application back in mid-2000 that was built to import Excel spreadsheets that were basically reporting output from MYOB (an accounting program). What had been done was to simply create a template table that had all the columns necessary to accomodate the report, using text data type for all columns. Then the non-data rows were filtered out and processed into the eventual destination table.
It's not elegant, and doesn't require a lot of programming, though the implementation I inherited used a dedicated temp table for each report layout that was being imported. You could easily replace all of those with a single table with 100 text columns of 255 (or memo fields, for that matter, if that was a requirement), and just re-use it.
I'm not sure if I'd recommend it or not, but it really is quite easy without requiring much in the way of code.