Nachträgliches Feld aus Tabelle wird nicht gelesen

Hallo Herr Stark,

folgendes Problem:
Ich lese mittels des SQL-Server-Adapters und einem kleinen Statement alle Felder einer Tabelle aus. Dieser Tabelle habe ich im Nachgang ein weiteres Feld (Date) hinzufügen müssen.
Diese habe ich auch über die Felddefinition hinzugefügt. Beim Aufruf der Definition bekomme ich folgenden Fehler: "Der Index war außerhalb des Arraybereichs".
Alternativ habe ich die Felder nochmal eingelesen, das funktioniert, d.h. ich kann über die Lupe auf der READ-Seite den Feldinhalt sehen, allerdings werden sämtliche Verbindungen vom READ-Adapter getrennt, obwohl das Feld als letztes hinzugefügt wurde. Das ist ärgerlich, da ich viele Definitionen mit erheblichen Aufwand überarbeiten müsste.
Haben Sie eine Lösung für das Problem?

Mit besten Grüßen
Kai Hauser

Hallo Herr Hauser,

ich vermute mal in Ihrem SQL Statement werden mehrere Tabellen abfragt und es kommen hier Feldnamen doppelt vor?

In dem Fall kann derzeit keine Eindeutige Zuordnung vorgenommen werden und die Verbindungen müssen erneut manuell verknüpft werden.

Kommen keine doppelten Feldnamen vor bzw. wird nur eine Tabelle abgefragt sollten die Verbindungen nach dem erneuen einlesen erhalten bleiben.

 

Hallo Herr Stark,

Danke für die Antwort. Allerdings frage ich nur einen View ab, das Feld kommt nicht doppelt vor. Nach dem erneuten Einlesen muss ich 10 Felder ObjectID löschen, beim OK werden die Verbindungen gelöscht. Allerdings ist das Feld dann lesbar, s. Anhang.

Gruß 
KH

 
 

Hallo Herr Hauser,

ich muss mir das mal etwas genauer ansehen. Melde mich ca. Anfang nächster Woche ob und wie eine Lösung in Sicht ist.
 

Kein Problem, das eilt nicht mehr ganz so sehr, da ich ab morgen im Urlaub bin.

Hallo Herr Hauser,

können Sie zur weiteren Analyse bitte mal den SQL des verwendeten VIEW posten, Danke.
 

Moin Herr Stark,

bin aus dem Urlaub zurück, hier der Script für die View:

SELECT        NL.TRANSACTIONDATE, NL.DOCUMENTDATE, NL.REFERENCENUMBER, NL.SEQUENCENUMBER, NL.ISUNFINISHED, NL.ISJOURNALIZED, NL.NOTE, NL.ISCANCELTRANSACT, NL.TRANSACTIONTYPE, NL.RATE, 
                         NL.TOTALAMOUNT, NL.PAYMENT, NL.PROCESSID, NL.VALUEDATE, NL.LEDGERTYPE, NL.SLIPNUMBER, NL.JOURNALNO, NL.DATEOFRECEIPT, NL.TAXDATE, NL.ISINPUTTAX, NL.TRANSACTIONNUMBER, NL.DELIVERYDATE, 
                         NL.TAXREGISTERNUMBER, NL.DOCUMENTCATEGORY, NL.ISCUSTOMER, NL.IMPORTAPPLICATION, NL.USETYPE, NL.ISDPAYFINALINVOICE, NL.NONETBALANCE, NL.BARCODE, NL.OIDNLTRANSACTION, NL.DEBIT, 
                         NL.QUANTITY, NL.DESCRIPTION, NL.AC0, NL.AC1, NL.AC2, NL.AC3, NL.AC4, NL.AC5, NL.AC6, NL.AC7, NL.AC8, NL.AC9, NL.ENTRYTYPE, NL.GROSS, NL.RECONCILED, NL.NLTRANSACTIONDATE, NL.NLISJOURNALIZED, 
                         NL.ISDISCOUNTABLE, NL.TAXVARIANCE, NL.NLISUNFINISHED, NL.NETAMOUNT, NL.ENTRYNO, NL.NLJOURNALNO, NL.SECONDARYJOURNALNO, NL.TRIANGLESALE, NL.NLTAXDATE, NL.QUANTITYUNIT, 
                         NL.ISDOWNPAYMENT, NL.DOWNPAYMDISCAMOUNT, NL.NONDEDUCTIBLETAX, NL.TAXACCOUNTTYPE, NL.OIDNLENTRY, NL.BASEAMOUNT, NL.BASECURRENCYCODE, NL.ENTEREDAMOUNT, NL.CURRENCYCODE, 
                         NL.SECCURR1AMOUNT, NL.SECCURR2AMOUNT, NL.SECCURR3AMOUNT, NL.SECCUR4AMOUNT, NL.OIDCONTRANLACCOUNT, NL.OIDCONTRAPERSACC, NL.OIDCONTRABANKACC, NL.ITEMTYPE, NL.ITEMCODE, 
                         NL.ITEMSHORTNAME, NL.ACCOUNTTYPE, NL.ACCOUNTCATEGORY, NL.CONTROLACCOUNT, NL.COMPRESSPOSTINGS, NL.SETTINGTYPE, NL.COSTUNITFIX, NL.QUANTITYTYPEISFIX, NL.ISPRIVATE, NL.POSTINGSTOP, 
                         NL.POSTINGSTOPDATE, NL.STOPNOTE, NL.COSETTINGNOTE, NL.ACCREGULATIONTYPE, NL.FINYEARCODE, NL.OPENDATEFROM, NL.OPENDATEUNTIL, NL.CLOSEMARK, NL.ENDMARK, NL.FINYEARNOTE, 
                         NL.DOCUMENTCODE, NL.ISBLOCKED, NL.DOCUIMPORTCODE, NL.DOCUMENTNOTE, NL.TAXSTOP, NL.TAXTYPE, NL.TAXIMPORTCODE, NL.TAXJURISDICTION, NL.TAXCODE, NL.BANKCODE, NL.BANKSHORTNAME, 
                         NL.BANKACCOUNTNUMBER, NL.BANKNAME, NL.BANKACCNOTE, NL.PERSACCOUNTCODE, NL.PERSSHORTADDRESS, NL.COMPANYCODE, COST.ENTRYOBJECTID, COST.MANAGER, COST.CCBTYPE, COST.CENTRECODE, 
                         COST.CENTRESHORTNAME, COST.I_VALIDFROM, COST.I_VALIDUNTIL, COST.UNITCODE, COST.COSTUNITTYPE, COST.CTBTYPE, COST.TYPECODE, COST.TYPESHORTNAME, COST.B_CODE, COST.B_SHORTNAME, 
                         COST.B_CTBTYPE, COST.OIDACTCOSTING, COST.QUANTITY AS SPLITQUANTITY, COST.CS_DESCRIPTION AS SPLITDESCRIPTION, COST.CS_SPLITNO, COST.CS_RATE, COST.CS_AMOUNT AS SPLITAMOUNT, 
                         COST.CS_AMOUNTFIX, COST.CS_AMOUNTVAR, COST.CS_BASEAMOUNT, COST.CS_BASEAMOUNTFIX, COST.CS_BASEAMOUNTVAR, COST.CS_SECCURR1AMOUNT, COST.CS_SEC1AMOUNTFIX, COST.CS_SEC1AMOUNTVAR, 
                         COST.CS_SECCURR2AMOUNT, COST.CS_SEC2AMOUNTFIX, COST.CS_SEC2AMOUNTVAR, COST.CS_SECCURR3AMOUNT, COST.CS_SEC3AMOUNTFIX, COST.CS_SEC3AMOUNTVAR, COST.CS_SECCURR4AMOUNT, 
                         COST.CS_SEC4AMOUNTFIX, COST.CS_SEC4AMOUNTVAR, COST.CS_CURRENCYCODE, NL.NLSPLITNO, NL.OBJECTTS
FROM            varial.TMPNLTRANSACTION_V AS NL LEFT OUTER JOIN
                         varial.TMPENTRYCOSTDATE_V AS COST ON NL.OIDNLENTRY = COST.ENTRYOBJECTID

OBJECTTS wird über varial.TMPNLTRANSACTION_V  aus einer varial.NLTRANSACTION_T AS T INNER JOIN geholt.

 Ich selbst frage den View wie folgt ab: 
select *  from varial.[PUBTRAN1CURRCOST_V] where COMPANYCODE = 'MDE' and TRANSACTIONDATE = '$TagesDatum$ 0:00:00' 

Der View selbst endet
select
...
      ,[CS_SEC4AMOUNTFIX]
      ,[CS_SEC4AMOUNTVAR]
      ,[CS_CURRENCYCODE]
      ,[NLSPLITNO]
      ,[OBJECTTS]
  FROM [VWE].[varial].[PUBTRAN1CURRCOST_V]

Hilft das weiter?

Hallo Herr Hauser,

vielen Dank für die Info. Es gibt leider keine schnelle Lösung. Mit der nächsten Version wird das Einlesen der Felder soweit angepasst, dass auch in diesem Fall die Felder nach einem erneuten einlesen weiterhin verbunden bleiben.