Onepax Business Consulting


As an application engineer I find that there are certain circumstances where having a GUI screen to perform a task is not always possible/practical.  There are many times that the client has given me access to the database server but not the application server and there are simply times I am going through upgrade steps and simply don’t have a working environment yet to perform tasks via the front end.   This week I needed to perform a SyteLine 7 to SyteLine 9 upgrade that put me in such a situation and I had to get creative to find a workaround.  For this customer one of the upgrade steps was to purge out all user scoped versions of forms from SyteLine 7 (not very many folks will spend time going through the process of FormSync and nor would I) however the newest version of FormSync was displaying nondescript errors on the delete operation.  T-SQL to the rescue!

On a side note, I want to point out that I absolutely love what Infor has done with new SyteLine Infor CloudSuite and believe whole heartedly that no other company gives as much built in functionality for the cost per license.  It is a very stable and mature product and it’s few and far between that I am forced to work around an obstacle from the back end.  Secondly, I enjoy writing neat scripts to streamline my interaction with the ERP system and will almost always jump at the opportunity even when my plate is full.

For this task I wanted to whip up something that I could use in the future as part of the SQL cleanup process of removing user scoped forms automatically without having to ever open FormSync.   My advice to everyone is to utilize the great tools that Infor provides to maintain your database health however I do realize that there are cases when fixing from the back end is a better route to go (assuming you know what you are doing and the logic is sound).  As always I provide this “as is” and is meant for educating and not to replace functionality which is already available via the product.

Note: I wrapped the code in a BEGIN / ROLLBACK TRAN so that results can be viewed without actually causing true deletions of forms.  When I ran it, I used a COMMIT TRAN instead so that it would really delete the unneeded form.  Download Code Here



 @FormID INT
,@FormName nvarchar(50)
,@Scope INT

set @Scope = 3 --scope 1 for SITE, scope 2 for GROUP, scope 3 for USER
if @Scope < 1 or @Scope > 3
  RAISERROR('SCOPE MUST BE 1, 2 or 3',20,1) with LOG

DECLARE FormDelCur cursor local static for
SELECT Forms.ID, Forms.Name FROM Forms WHERE 
  [ScopeType] = @Scope
  --AND [Name] = N'JobOrders' 

open FormDelCur
fetch next from FormDelCur into @FormID, @FormName

while @@FETCH_STATUS = 0
   DELETE FROM FormEventHandlers WHERE FormID = @FormID
   DELETE FROM FormComponents WHERE FormID = @FormID
   DELETE FROM ActiveXComponentProperties WHERE FormID = @FormID
   DELETE FROM Variables WHERE FormID = @FormID
   DELETE FROM FormComponentDragDropEvents WHERE FormID = @FormID
   DELETE FROM DerivedFormOverrides WHERE FormID = @FormID
   DELETE FROM ActiveXScripts WHERE [Name] = @FormName AND [ScopeType] = @Scope
   DELETE FROM ActiveXScriptLines WHERE [ScriptName] = @FormName AND [ScopeType] = @Scope
   print 'Successfully deleted form ' + @FormName + ' with ' + CASE when @Scope = 1 then 'SITE SCOPE'
                                                                    when @Scope = 2 then 'GROUP SCOPE'
								    when @Scope = 3 then 'USER SCOPE'
   fetch next from FormDelCur into @FormID, @FormName
   print 'Unable to delete form ' + @FormName + 'with ' + CASE when @Scope = 1 then 'SITE SCOPE'
                                                               when @Scope = 2 then 'GROUP SCOPE'
							       when @Scope = 3 then 'USER SCOPE'
   fetch next from FormDelCur into @FormID, @FormName
close FormDelCur
Deallocate FormDelCur

  December 4, 2015      Comments (0)