InfoPath Dev

I've seen many posts on this topic. Unfortunately I haven't found a solution for a very specific naming convention that I'm hoping there is a solution for. Codeless perferably but either way. The naming convention is as such    H3-RFR-KED-MRC-1

The H3-RFR- is static. The "KED" & "MRC" are both pulled from 2 seperate drop down lists in the form which describe the path of a workflow. The "1" is the @ID, looked up from the sharepoint site. The issue I have is number increases sequentialy, regardlessof the path. Ideally I'd like the naming to follow as such . . .

H3-RFR-KED-KED-1

H3-RFR-KED-MRC-1

H3-RFR-KED-KED-2

H3-RFR-MRC-KED-1.

Where each new 'path' combination would start at 1, but if the path is not unique the number increases by the max total of that combination +1. Is this at all possible? if so can someone point out where I can find that solution.

 Cheers!

Hi --

I need to first point out that you need to be careful with names like these, and when you create them -- if you create the name when the form is first opened, and the next available number is 2, but someone else opens a new form before the other form has been submitted, you could end up with a conflict (two "2"s).

So, you definitely want to do this at the time of submit, and if this is a heavily used form, you'll need to do something different -- use date & time to the second (or millisecond), for example, or leverage a database table and "reserve" file names for forms on open....

All that being said, the simplest method would be to query the library where the form submits, and pull back the form titles. It seems like it might be possible to use XPath to get the one that matches up to the final digit, and then some substring functions to return just the number after the dash, at which point you could increment the number.

Of course, this has its own set of perils -- a standard SharePoint list connection is going to pull back only items from the default view, and if you have a limit on items per page, I believe it will respect that limit. If your library is going to be huge, you'll be pulling in a pretty big list (since it is just title, maybe not too sluggish, but you'll need to keep that in mind).

So, I realize this may be discouraging -- and I kind of intend it to be -- you can use promoted properties in your library to expose these form values instead of relying on the name -- you could even promote a field that concatenates all the values w/out the number and group your view on that field, with items sorted by created date, which would give them to you in the same type of order than you would get from sorting by name with your naming convention. Use date & time in the file name to give yourself a better shot at uniqueness without all the fuss.

Just my somewhat unrequested 2 cents...

Another reason why SharePoint IDs are not preferred is because they change when the forms migrate from one SharePoint site to another. We advocate using natural keys for ID'ing forms. For example, a date-time stamp instead of an ID. Granted, the date-time stamp is not as easy for humans to handle because it's large, but if you encode as year-month-day-hour-sec it has the added advantage of telling you when the form was first created which is useful.

Thanks for your advise, unfortunately, my employer is dead set on a specific namin convention format. What I have done is use the ID from the list. Set a submit button on the form with rules to 1st to populate a hidden text box with max(ID)+1 from a data connection st to receive the ID from that list, then submit the form with the concat("namingconvention", Textbox Value). Then I set the list to organize by ID descending that way the latest ID number will always be in the view so I wouldn't need to worry about the list item limits. Seems to work ok.