Infopath data connection to sharepoint: how to avoid hard coded list id? - sharepoint-2010

I've created a infopath 2010 form with a connection to a SP list. This connection allows me to populate a drop down list. This is working as expected if I work on an existing site.
Now I want to publish this form as a task form of a workflow feature. the workflow is part of a site template that also defines some list instances. As list instances have new IDs each time they are created, the form data connection won't work (listID and spweb absolute url are hard coded in the data connection in the xsf file).
Is there a clean way to allow me to populate a DDL in infopath without the actual list id ?
In fact, can I bind to "lists/mylist" instead of {myguid} ?
thx

(angry against Microsoft for using guids everywhere without the ability to control them).
I finally followed this approach :
In my forms, I converted the data sources to datasources shared in the host sp site. This generated for me the udcx files.
Then, I created, in VS 2010, a feature with a module to provision a DataConnection library, holding all this udcx files. In this udcx file, I replaced the GUID with tokens like $listguid$ or $weburl$
I also wrote a feature receiver to replace, after provisioning the module, my tokens with the actual values
quite painful and very disappointed with this big holes in SP development processes

Related

Breaking out Component VB from Access Application

I'm looking to break my access applications out into their component pieces so that I can use some version of source control with it. I currently have separated the front end and back end database. However I would like to go one step further and separate out the front end logic in the forms into their component files. If someone could point me in the right direction it would be much appreciated.
Access for about 20 years has supported the standard source code control interface.
The fact that the project is stored in one file is MOOT since Access can “logically” view each individual item (forms, reports, query, code etc.) as a separate object. So don’t confuse a logical view of the application vs that of physical.
There are quite a few posts on SO that outline this, and this post here gives some more information:
Version control for VBA file
When you use SCC with Access, then you see this:
if using Visual Source safe, you see this:
If using Team foundation server, you see this:
And the UI inside of Access shows the status of such objects. eg this:
There also add ins for git hub etc.
Keep in mind that Access 2010 was/is the last version to support SCC. If using 2013, then you have to use the noted "save-as-text" to send out each part and code as a standard text file which then of course can be used by any standard source code provider/control system.

Custom Building Block Template wont load reliably

My small collection of document-specific macros and quickpart building blocks is growing! I'm starting to share these with employees, and am looking to be able to set up each remote computer once only. From there on, update collections on a network path. And because each computer looks to the shared location, everyone should always be working with up to date macros and quickparts etc.
So. What I already know:
- Required macros are saved in a separate module, ready to be shared/exported.
- Macros themselves occasionally reference local paths on my computer.
- I will need to reference paths with generic code or use Environ variables.
- Building blocks and quickparts are saved in a separate template file (currently located in Appdata, along with default building block file).
What I dont know:
a) How to point Word to a network path to retrieve macros from custom macro files. (Would I just have to import a fresh macro file at every important update, on each PC?)
b) What's the best way to load a building block item from a CUSTOM path?
My custom BuildingBlock template file is not loaded properly on occasion:
Dim objTemplate As Template
Dim objBB As BuildingBlock
'set template to store the building block
Set objTemplate = Templates("C:\Users\[USER]\AppData\Roaming\Microsoft_
\Document Building Blocks\1033\CustomBBlocks.dotx")
Set objBB = objTemplate.BuildingBlockEntries.Item("[EntryName]")
I know this because the code spits out a 'CollectionDoesntExist' error unless I click the Quickparts gallery prior to running the code for the first time. So it's like Word cant be bothered to open the template file and look inside unless I do it from the UI first.
Of course, if I first open the Quickparts gallery from the UI, prior to running my code, Word seems to figure it out, and inserts the correct Building Block entry without any issue.
In the past I've worked on a product that allows building blocks for Word too. Some sites have hundreds of templates and maybe 1.000 elements (see Composition). The approach we've taken was successful and was different.
You are trying to deploy software elements (macros) across a large number of workstations. You can try to get it working using the possibilities of Microsoft Word and Windows, but it will be sensitive to problems when things change. For instance, switching to Office 2013, splitting a domain into two, work at home without VPN, etc.
Option 1 - DIY deployment: Better put the macros and other stuff behind a webpage, webservice or alike. Deploy on each workstation a generic program that pulls in everything and deploys it locally. You might want to hand over some parameters to the webpage being called to restrict the amount of data. You might want to cache things locally.
Option 2 - Use ClickOnce: write a clickonce deployment script, include the necessary references and put it on a shared network drive or http address. ClickOnce automagically upgrades your software when it finds a new version. It even works across the internet. And it does nothing when there is no new version.
Option 3 - Database: put the elements centrally in a database, allowing end users to change building blocks through forms. Have Microsoft Word in combination with a ClickOnce program pull them in.
For Composition we've used option 2 and 3.

SharePoint Integrated Reports missing drop down to manage data sources

I have installed and configured SSRS using SharePoint integrated deployment mode and have been able to successfully run a report from SharePoint. I created a custom deployment application that will upload all reports and datasets as well as create all data sources and make the proper connections between them when necessary.
I have one report that failed and I need to manually mess with the reports connection to a data source but I found that the drop down does not contain the options to let me manage its shared data sources (see example below).
In this image you can see the option that I am missing. Please excuse the colors, this is the best image I could find online in a pinch.
This is only happening in one environment so there must be a configuration change I am not thinking of to show these options. Here are the things I have already checked:
The account I am using is in the sites Owners group and has full control of everything, including the report file.
The item is being uploaded as a Document content type for some reason, but I edited properties and changed that to Report Builder Report content type.
The Report Server Integration site collection feature has been activated.
All of the Reporting Service content types have been added to the list.
I would revert to deployment from BIDS to debug this issue. It will perform some validation during that process and possibly return meaningful errors.
So this turned out to be caused by one of our customizations. We had an old custom javascript function that was named the same as a SharePoint javascript function that has something to do with those drop down actions. Hope this helps someone else.

Synchronize 2 SharePoint Libraries on Different Servers

I need to copy or synchronize 2 libraries between 2 different servers. Here are more details:
1- I have an InfoPath form that is submitted to a document library, Lib #1.
2- The InfoPath form is published as a content type and Lib #1 is configured to deal with this content type.
3- The users will have the ability to add new items to Lib #1.
4- At the end of each day, or may be every hour or so, I need to copy the newly created items or sync Lib #1 with another library on a different server.
5- The content type will be available in both servers.
I am new to SharePoint so I appreciate if you can show me some hints on how to achieve that.
Clarification
I don't know which route to take, I am thinking of utilizing any of these (if possible):
1- Replicating Database: Use replication to copy data from one SharePoint database to the other
2- File System: I am not sure if the forms are saved in file system but if they are, I could copy the forms from one server to another.
3- Programatically: I am reading about SharePoint server events. I can program against the List Item Added event and try to copy the item from one server to anther.
4- Built in: May be there is a built in tool that I am not aware of that can help me copy items.
Why do you want to do that ? If the target is entirely different server, forms won't open from there unless you relink the documents and you have same form template deployed on that server.
To do this job, you have two options:
Realtime - Use ItemAdded event handler, to copy the item to target as soon as it is created.
Timer Job - You can create a timer job which will run as per some schedule and copy the items from one library to other.
Reject the DB and file system approach. Accessing DB directly is not supported. And these are not stored on filesystems. SharePoint API is only way. You can use either in Event handler or timer job.

How to retrieve a list of tableadapters?

BACKGROUND:
Most of my programs use table adapters, and the connection strings are stored in app settings. This works fine, but was a real PITA when switching from development to production environment. I had to change manually the connection strings before and after starting my work on any app.
After a bit of research I found how to switch connection strings for table adapters dynamically. By simply adding a custom property for connectionString, I was able to acheive this. But I still have to add code in the new event for each application so the connection strings get switched when it loads. (My connection strings are kept as an app property setting in a common DLL. I just keep one copy of the DLL with my connection strings locally, and one copy o the DLL with the production connection strings on the production server.)
NEW PROBLEM
I'd like to take this one step further and have either have the datasets change the connection strings for all table adapters they each contain when they load using the new event, or do the same from a VB module. I may have up to 3 datasets at any one time.
I do depend a lot on intellisense to help me determine which methods and properties are available, but I can not find a way to retrieve a list of the table adapters in my datasets. It does not appear that they are a part of any collection of objects as far as I can tell. I've searched a quite bit for a solution, but no luck.
Marshall
You might want to reconfigure the location of the connection strings. Make your presentation layer (i.e. the application) contain the connection string in it's app.config. Now here's the cool part ... any .DLL that is being used by the application can access the application's app.config using the ConfigurationManager.ConnectionStrings("MyConnectionString").ToString function. Your .DLL would call the connection string by name, and the call propagates up to the application's app.config. If you don't want to hard code "MyConnectionString", then you should simply pass the connection string to the .DLL via a property of an object.
If you DON'T want to rearrange the connection string "ownership", simply expose the .DLL's connection string from it's own config file via a static object in the .DLL which the application can read. Assign that to the TableAdapters.
As a side note, if you are already familiar and comfortable with what appears to be your custom DLL's, move all of the data access logic into its own DLL as a Data Access Layer (DAL) - get the data access logic out of the presentation layer!