InfoPath Dev

I only have PDF read only.  I think that is the reason I cannot export to PDF from the InfoPath File menu bar selection.

I wonder if the PDF form is editable as opposed to Word, when I do an export?

I currently have a major problem with the form, I have added "lines of code" variables.

And One line seemed to make the System think that I had created an infinite loop???

I thought I deleted the controls.

The error persisted.

I deleted the Print View Form version 2.

Problem still persists.

I deleted the First Print View form.

Problem still there.

I deleted most of the variables on the Main form.

Problem still there.

I have contacted InfoPathdev.

But, they keep saying that there is a infinite loop.

But no clues how to find it.

I have opened up aShldr_proforma_template version of a month ago, linked it to the database I used.

And NO PROBLEM.

So the problem is not in the Access Database.

Where is it???

Onn further analysis.

I found that a couple of Access fields further along were to small for the text being inserted. An error was being produced.

And at the same time the infinite loop was appearing.

I corrected the fields that were too small. Any errors appearing before, are now not showing.  ????????????????

However. Not all the controls are appearing now.

It may relate to the number of Rules exceeding the limits on Infopath.

If you have any alternate suggestions please advise.

Ian

Talking to myself.  And the rest of the world.

please see the other message I posted today.

The errors have reappeared and other problems continue to plague me.

Looking forward to a reply.

Ian

Which other message?

Ian, your posts are kind of erratic with many short (one line) paragraphs, so I have trouble keeping up.  It's like your typing while out of breath (makes me winded just reading it).  I think it's very difficult for anyone to resolve the problem or help you without truly understanding the problem.  I can't speak for everyone, but most threads get at least some answer, so that leads me to believe most of us don't understand what's going on.  I have read this post twice before and just moved on, because I was confused, but I'll now try to help if you can corral your thoughts.

Hi,

If you can follow all of the posts I have been sending over this year.  You might develop a picture of what I am onto.

However, I shall give you a brief here 
When god created man. starting with adam and eve etc, etc. blah blah blah unitl the present century and year.

Now InfoPath was developed in about 2003.

I came on board Nov 2008.

I started developing  InfoPath forms.

As time went by, the form became more and more complex, with the changing user requirements.
And the limitations of MS Access and InfoPath.

I had to learn work arounds to get things solved.

Now, the project I am working on, has over 200 fields (controls).

I have a user input form.
And a Print View form, and a form to rehash controls into other controls that look like lines of text.

Because YOU CANNOT simply create forms for MS WORD . The alternative is to create MS Access fields that can be copied and or written directly to MS WORD.

Now my Form is c0omplain about record too large. and infinite loops, cannot update, And refuses to make fields (controls) appear in the later half of the form.

So it is a mystery.

Hopefully, it is a little clearer for you.

Ian

Hi Ian,

Sorry to hear you didn't get the InfoPath to Word thing working well. I don't understand why you would be using Access as a go-between for InfoPath and Word. That sounds strange to me.

Here's a stupid question: are you sure InfoPath is the right tool for what you are trying to do?

OK, back to reality. Now, just because InfoPath gives you this promise of codeless solutions, doesn't mean that you can go cave-coder on the thing and expect it to magically fix all of yoru bugs. For sure, if we are going to pull you out of the current mine shaft that you are in, it will require active debugging. We'll need to set up a live meeting and go deep spelunkering through your solution. To do that will require some kind of consulting retainer.

In summary, the kind of problem you are having is not conducive to forum help. You need to get someone there beside you or virtually connected to you and debug the issue. Forum posts are disconnected so it's hard to get enough detail to debug a code issue. This forum is meant to help those with common issues and gotchas. It is not meant to help people write or debug code. Sorry for the brutal honesty.

Keep up the faith!

Hi Patrick,

Thanks a mountain for you response.

I think, I have found the eror. It is as the message appears.

Let me explain --

I have a lot of controls.

and lots of controls to resemble print lines.
Now, I used concat and RULES, to conditional add fields to the print line controls.

So, in one case, I have 8 rules, to assemble the print line. Unfortunately, the system seems to think that current value for the field could be any place, any time.
I know each rule is processed in order from first (on top) to last (on the bottom of rules list for field). But, the sysem dosn't know when to start, or stop.

Example for print-line-2 control
Rule 1   : print-line-2  = string("Please thank the ")

Rule 2  :  if gender = M ===>  print-line-2  = concat(,print-line-2,"Gentleman").

Error only appears when running application.

My work around now is to create a few more MS Access controls.

Rule 1 : if salutation1 not blank  extra-field1 = "Please thank the "
Rule 2 : if gender = M ===>      extra-field2 = "Gentleman"
Rule 3:  print-line-2 = concat(extra-field1,extra-field2).
I.E. print-line-2 has no reference to itself. 
The above is a simple example, the fields are not blank, or blank.

Sad there is no way of overcoming that.

Looking forward to an easy outcome.

Ian

PS

I spent half the night adding extra dummy controls, then copying evberything to a new database. Access seems to have a short coming with its controls memory counter.

Originally I has ONE table, then 6.  Now Eight. 

Hope it is over soon

Hi Ian,

I don't know enough about your specific requirements to say this definitively, but I do suspect you are creating more work for yourself by using Access controls. I have developed hundreds of solutions over the last 10 years using Microsoft Office and specifically InfoPath, SharePoint, etc. And, I've only seen Access in use to print forms that had to match an image provided by the government. Not that Access isn't cool and all that, but it's not usually a solution to InfoPath. In the case where we have seen Access in use (and condoned it), it was for a specific wyswig printing requirement. InfoPath does not have good printing support, so the Access report used an image and overlaid it with fields that were populated from a SQL database. The InfoPath form submitted data to that database. The problem with this solution is that the printout is hardcoded and required a lot of work to redo when the government changed their mind. Too bad multi-page forms don't print better with InfoPath, but some day I suppose printing will be less important.

I'm sorry we can't be of more assistance, but you have one crazy 6 sigma solution.

Cheers, 

Thanks for the reply Patrick. It is really appreciated.

As you say there are limitations with MS products and interfacing between them, and the printer etc.

I am sooo involved with the MS Access. And the hours involved in converting to SQL would be terrible.

I am only using the Access as a database. Holding all the data I am designing in InfoPath.

Access has, as I mentioned above, forced me to build a new Access DEB, due exceeding the data limits. Very annoying.

I have only ever used SQL briefly in the past. Designing the db, to me would seem a major headache.
I was using SQL 15 years ago.

Now if I could wave the wand, and convert the Access to SQL, fantastic.

I think SQL is Heirarchical?
The same as Access.
And in SQL, referential integrity is always on. Unless there is a switch to disable it, if neede. I am not sure.
My data pretty much passes the integrity. Only until, as from my past dramas, could not attach a supplier table. If you recall.
So I copied some supplier fields into the customer record.

I am feeling confident that again I should have a solution soon.

I am having a break at the moment. 2 days,
because of the flu and gout (right wrist), the is easy to fix. 
If you always drink plenty of water, you should not suffer from gout.

I am always forgeting to grab a glass.

Regards

Ian

Patrick, the message you forwarded, as shown below, seems intersting. First, I  would like to get SQL (server) working on my computer, but I am having trouble setting it up. I can get the server config stuff down. But I don't know, seem to be able to create a database.  So, I shall rely upon my MS Access.

With the last Blogg I published, I declared I had found the solution to  my inifinite loop error.
Hopefully you have seen that. From your remarkes below, do you mean that Access is the culprit for the Calculation limitations?????

Or, as I am thinking, it is all part of the InfoPath system!!!  Can you clarify which way it might be.

And, what do I have to do to create an SQL database, As, I think, I have set up SQL server processes on the computer.

Looking forward to your comments on the above two.

Regards,
Ian

****************************************************************************************************************************
Re: Can you help, I have an infinite loop problem that won't reveal itself 

 don't know enough about your specific requirements to say this definitively,
but I do suspect you are creating more work for yourself by using Access controls.

I have developed hundreds of solutions over the last 10 years using Microsoft Office and specifically InfoPath, SharePoint, etc.
And, I've only seen Access in use to print forms that had to match an image provided by the government. 

Not that Access isn't cool and all that, but it's not usually a solution to InfoPath.

In the case where we have seen Access in use (and condoned it), it was for a specific wyswig printing requirement.

InfoPath does not have good printing support, so the Access report used an image and overlaid it with fields that were populated from a SQL database.

The InfoPath form submitted data to that database.

The problem with this solution is that the printout is hardcoded and required a lot of work to redo when the government changed their mind.

Too bad multi-page forms don't print better with InfoPath, but some day I suppose printing will be less important.
*************************************************************************************************************************************