Can you take a look at the FBLayout table in the Footprints database in SQL? This table contains both a live and draft copy (if applicable) of the form for each workspace. Does your table have data in it? Do other workspaces behave properly when going to Admin|Workspace|Form Designer?
Thanks for the reply Mike.
I should have mentioned in my first message, I checked the other workspaces and they are working fine. It's only our one workspace having the issue.
I have an email into our SQL admin to check those tables. I'll report back when I know more.
Go to c:\footprints\db\MsterXX\MR and check if you have a file called FBDesignData.json
If you have this file, than go to your Database and run this querry:
delete from dbo.FBLayout where WsID = 'XX'
(XX: your workspace number)
Go to the Form designer and publish the form without making any modification.
Let me know if this will work for you,
We had the file and performed the query. Now we are getting the following message trying to access the Form Designer, create new tickets, and access existing tickets:
502 - Web server received an invalid response while acting as a gateway or proxy server.
And just fyi, this is only happening in the one workspace.
1 of 1 people found this helpful
I would delete the FBLayout file in the MR directory and then resync the database from Administration - System - Workspaces and then try again.
We don't have an FBLayout file in the MR directory. Did you mean FBDesignData.json?
1 of 1 people found this helpful
If you delete the FBDesignData.json file you will lose all your dependencies and the placement of your fields…
I don't think the 502 error is related to the form designer.
I am not sure, but try to run the MRChangePermissions.pl
Yes sorry I meant the .json file, if that file gets corrupted it can cause that issue, but Jean is correct it will cause you to loose all formatting and dependencies. Try renaming the file to .old and see if that fixes the problem.
We tried renaming the file and that had no affect.
I'm still working on getting the access to try running MRChangePermissions.pl to see if that has any affect but my System Admin has been unavailable.
Running this .pl script didn't fix the issue either.
Still getting the "Init failed" message and the 502 error opening an existing ticket.
Since the issue is specific to this workspace try creating a new workspace by copying this workspace and see if the problem is copied or fixed in the new workspace,
We used the combined effort of deleting the table rows and renaming the .json file and we were able to access tickets again. However, after making subtle changes to the Form Designer and publishing, it broke again. We'll be contacting support. Thanks all for your help.
This weekend, I upgraded our production Footprints system from version 10.0.1 to version 11.1.0. I had this same problem, and in fact it was this very thread we found after performing a google search and got us moving forward again. I did not encounter this problem in my Test Footprints environment so I was unprepared to deal with this. And since it was a weekend I couldn't call BMC for support.
We had all the same problems. Form Desiner gave us the 'Init Failed' error. We got IIS 502 errors when attempting to open an existing ticket, etc etc.
We deleted the rows from the fblayout table where wsid equaled our troubled workspace. Then we sync'ed the schema with the database. That brought back all our custom fields into the database and Form Designer. From there we used Form Designer to adjust the fields as needed.
One problem that really irritated me was the fact that Footprints updated the two Windows services that Footprints uses. (I'm talking about the Footprints Schedule Service and Footprints Watch Service.) Footprints upgrade deleted and then re-installed those services. When they were installed, they were set to run mode. Which means Footprints immediately reached out to our email system and began processing emails and turning them into tickets. I couldn't catch the services in time - we had approx 85 tickets processed over a two hour period. Nearly all of them triggered escalation rules we had defined, but because our database was messed up after the upgrade (we hadn't yet sync'ed the schema) many fields didn't get inserted into the database.
Support provided us with the explanation that it was related to our custom HTML we had in version 10 that was changed into "instruction" fields in version 11. The fellow I spoke to noticed we were using tables to display some of our custom HTML headers to break up our tabs into different sub-sections.
As soon as I removed all the instructions (which I was going to be doing anyways), everything was fine.