Dynamics Community Forum Thread Details

PSTL seeing deleted tables

We were having issues combining GL accounts in PSTL. We found there were some extra tables in the GP databases that were
created as backups or used to assist with importing data into GP when creating a new company. Deleting the extra tables fixed one of our
companies, but we have an odd issue with one of the other companies.

We deleted table XYZ. When I ran the combine I received an error saying /Invalid object name XYZ/. We put the table back with one

non-GP column name and no data and the error changed to /Invalid Column Name 'PMDTKIDX'/. That was the first column in the deleted table.

We then put table XYZ back, with the original column names and no data. We then received /Invalid object name ABC/ which was one of the
other tables we deleted.

How is PSTL still looking for these deleted tables and how does it know the original columns that were in them?

Thanks,

Marilyn

Categories:

Microsoft Dynamics GP

Hi Marilyn,

This the main SELECT statement inside of taAccountIndexCombiner that drives the looping of updates from account index you're combining from and into:

SELECT 'update ' + o.name + ' set ACTINDX =' + rtrim(@I_intEndAcct) + ' where ACTINDX = ' + rtrim(@I_intStartAcct)
   FROM sysobjects o
       ,syscolumns c
   WHERE (
           o.id = c.id
           AND o.type = 'U'
           AND c.name = 'ACTINDX'
           )
       AND (
           o.name <> 'GL00100'
           AND o.name <> 'GL00100F1'
           AND o.name <> 'GL00100F2'
           AND o.name <> 'GL00100F3'
           AND o.name <> 'GL00100F4'
           AND o.name <> 'GL00105'
           AND o.name <> 'GL10001'
           AND o.name <> 'GL10110'
           AND o.name <> 'GL10111'
           AND o.name <> 'GL00201'
           AND o.name <> 'GL20001'
           AND o.name <> 'GL30001'
           AND o.name <> 'MC00200'
           AND o.name <> 'MC00201'
           AND o.name <> 'MC00300'
           AND o.name <> 'XLImport'
           AND o.name <> 'XLActInf'
           AND o.name <> 'MC30001'
           AND o.name <> 'DTA00300'
           AND o.name <> 'DTA00301'
           AND o.name <> 'SE90001'
           AND o.name <> 'SE810000'
           AND o.name <> 'SE000200'
           AND o.name <> 'SE00400'
           AND o.name <> 'SE000401'
           AND o.name <> 'PA10704'
           AND o.name <> 'PA10705'
           AND o.name <> 'PA31104'
           AND o.name <> 'FA42200'
           AND o.name <> 'POP10390'
           AND o.name <> 'POP30390'
           AND o.name <> 'POP10360'
           AND o.name <> 'POP30360'
           AND o.name <> 'AAG00200'
           AND o.name <> 'AAG00905'
           AND o.name <> 'AAG02001'
           AND o.name <> 'IF000003'
           )
   ORDER BY o.name

To get an idea of all tables, you could maybe just run this. This would be runnable in SQL and gives a resultset showing a list of tables the process is trying to update through the combine process. My guess is offending table(s) should jump out in list (if you were to somehow accidentally actually run the updates, it shouldn't do anything since no account indices would be -1 and -2).

DECLARE @I_intStartAcct INTEGER=-1
DECLARE @I_intEndAcct INTEGER=-2