InfoPath Dev

Sure. If you put the now function in an expression box and look at it you can see a couple options.  I typically use the substring-after and then use the "T" since that seperates the date from the time. substring-after(now(), "T") You could break it down farther to eliminate the seconds if you wanted by just having ...

Hi Becky. Welcome to the forum.  I would recommend databasing the forms for long term storage and audit trail.  I would look at Qdabra's web services.  With them you get the functionality to store even versions and all the data. Another option would be saving a view and exporting it as a pdf or something.

Well.  I had used this in InfoPath 2003 and XP tablet. But just trying it with Vista and 2007 SP1 I was able to confirm that I could not get ink on a picture, and reading again a background image is optional. What OS and IP version are you using?

Have you tried putting a picture in the control?  I believe you have to have that first and then can ink on top of it.

Have you put a base picture in first? I believe you must have a picture to ink on and cannot just ink in the control.

Hey Rico. I worked with Jim on a full DBXL install on 2008 and 64bit with MOSS and we had to remove the automatic webdav fix to get it to work correctly.  I am not sure how similar the stand alone AD service install is but there may be an issue with that configuration.  I beleive Jim is working on 2008 / 64 bit testing and verification.

Hey Todd. Not sure how complicated you need this to be...  I am assuming you are wanting to minimize any coding into the form itself and want it to be as dynamic as possible. I am assuming you have a list of Customers that are coming in as a secondary data connection. Obviously if you had additional fields in this list that could flag ...

A limitation of Access and InfoPath is large field types are not supported becasue of performance. You would need web services and SQL. Or possibly some code could override this. Have you tried just using large text fields? nvarchar(250)?

Definetly using Access with a browser form is not best practice and I did not think even supported.  You must be using code to do this. I would move the data to SQL or a BDC and then setup UDCs in SharePoint for your form data connections.  14 fields should not take very long in this scenario.

Hi there. Welcome to the forum. You have a couple issues. One would be the size of your database in Access and the other is probably how you have it set up. InfoPath has some constraints to how the table is setup. You have to have a primary key. And any child tables must have a foreign key relationship. In you scenario I do not think you want ...