InfoPath Dev

 Hi all,

 I'm hoping to set up a server that runs MSSQL 2005 and serve InfoPath running on Sharepoint or something.  However I'm not exactly sure what kind of licenses I will need for each one.

Some brief information on I have right now are these:

1. Multiple users (over 100) each with their own computer will be required to open an InfoPath form and fill in the form
2. Each computer has Office 2003 with InfoPath installed
3. Users are on a domain
4. There will be multiple levels is security for different forms.
   

From a little research, I think I will need a 'Processor license' for MSSQL 2005 since it doesn't seem reasonable to get 'Device CAL' or 'User CAL' licenses.  However I'm not exactly sure, because say after a user fills in a form and submits it, I want it to write to the MSSQL database.  Does that count as a database connection, hence a license or would it be possible to just use one 'User CAL' license?

Also, will I need additional licenses for InfoPath for users to log onto the server that is serving the forms?

 Thank you very much in advance~!

i.f

You should definitely be talking directly with your MS rep who you do business with for your enterprise agreement or whatever it is your company has for Office.  It's all usually bundled up into one agreement so that your costs aren't full retail, and then you have to work with them to determine the best licensing for your situation. 

You also need to 100% decide on whether you'll be using SharePoint or not.  That is not an arbitrary decision, because SP has its own licenses...again, unless you have an enterprise agreement that covers all Office products (MOSS is an Office product).  If you are going to use SharePoint, will it be just WSS 3.0 or full MOSS?  The licenses for MOSS are separate from the SQL licenses, which will be per user, per connection, or per processor (I think, but it's a very confusing system).  Anyway, it's not a typical scenario for the InfoPath developer to be worrying about licensing as it's highly unlikely you'd have an entire SQL server just for storing InfoPath data.  You would most likely piggyback with one database on a much larger, existing SQL server.

Thanks,

 Maybe I should slow myself down a little first before jumping into all this.  Just about 2 weeks ago, someone was able to set up a Windows SharePoint Server 3.0.  So far it's been working quite well and I guess that answers your question, I'm going to use WSS 3.0.  So what I have in mind is to also include some InfoPath Timesheet forms for users to fill in and submit.  Is there an actual limit to how many users as access/use WSS 3.0?

The MSSQL 2005 server will just be acting as a database to store the timesheet information, every time an InfoPath form is submitted.

I will talk to my IT guy and ask if we have an MS rep.

Thanks again

Ok, so a few things to note.  WSS 3.0 is free software, so you don't need licenses for it, but you would still need whatever licensing is best for the SQL server being used for SharePoint.  As for your forms, they won't actually be going to the database the way you may normally expect.  They would go to the SharePoint form library.  Behind the scenes, all SharePoint data is stored in SQL content DB that is part of the SharePoint farm, but it's not a DB you directly interact with.  It is possible to create your own separate DB with tables that you build to either retrieve or submit data from your form to the DB, but that's a completely different beast than just submitting your forms to SharePoint.

So, did you intend on building a complete database structure for your timesheet data in SQL and then plan to interact with that data directly or through a web service from an Infopath form?  Or, did you just mean you were going to have it published to SharePoint and users would go to SharePoint to fill out and submit forms with the data residing in SharePoint (within the forms themselves but visible as columns in the library)?

As for someone the comment that "someone was able to setup WSS 3.0 2 weeks ago," be very careful with this, because if it was just someone tossing it up without architecting it or planning for usage, scalability, security (and all that jazz), then be careful about building a solution that people would potentially use for production purposes . If you are just building a prototype as a proof of concept, then great!  Just don't build it with the intention of employees using it for real unless you know the system was architected for production, long-term use.  WSS 3.0 is free and is very limited, so you wouldn't want to go too far down the rabbit hole without knowing what's on the other side.