Publishing to WSS 3.0 as web enabled form.

[Harold P.]

Hello,
I have developed a mileage expense form using Infopath 2003 that is
connected to our SQL server, and has been in production for several months.
I am looking to publish the form to our WSS 3.0 server as a web based form
(exclusively) using infopath 2007. My question is: wiil this have any effect
on the current form that is published to a network location? And also, if I
decide to remove the form from the WSS server, will there be any effects?
This is because people will still use the from in a network location (using
infopath 2003) until I "go live" with the form on the WSS server. Thanks in
advance.

 

[Greg Collins]

Having your form in two separate locations should not affect the
functionality of either form. They should both work independantly from each
other, even though they are tied to the same data source.

The only thing you might want to watch our for in your form is the issue of
more than one person updating the same row of data at the same time.

 

[Harold P.]

Hey Greg,

Thanks for response. Been away for a couple days and couldn't respond.
Anyways, I'm glad you brought up the issue of people updating the same row at
a time. I have been getting intermittent issues with the form in which I
recieve an error message ("... rules did not apply."). Upon looking at the
details, it mentions that some rows have been changed, and cannot be updated
(something to that effect). Is this the type of error that occurs when
multiple users attempt to submit to the database (same row) at the same time?
Again, this happens irratically and has been bugging me because I know the
form is working, but I can't seem to figure out why it's throwing that error.
Thanks in advance.

Regards,
Harold P.

 

[Greg Collins]

That sounds like the kind of issue I was talking about. What's likely
happened is that someone else updated the same rows before this person tried
to submit. When the submit happened, the backend checks to make sure the
data pulled down is the same as the data existing. If there's a discrepency,
then it reports it back and disallows the submit so as to prevent data loss.

The user would need to refresh their data and make their changes again
before submitting, but might run into the same issue yet again.

The best thing would be to find out which rows were changed in the
background, and somehow refresh just those rows, maybe showing the user the
both sets of data so they can merge, leave the new, or clobber with their
own. This can get quite complicated.

Another option is to figure out some kind of a locking system, where when a
user pulls down data to work on, it gets marked as locked (with an
expiration), so that other users cannot edit until the first one is done.
This can also get complicated.

Good luck!