none
SELECT schneller als INSERT RRS feed

  • Frage

  • Hallo,

    ich habe folgendes Problem, welches zwar nur sporadisch auftritt, aber trotzdem für unsere kunden sehr unschön werden kann.

    In der Software wird ein neuer Datensatz eingetragen und gespeichert (mittels Insert-Prozedur). Die Tabelle hat noch einen Trigger, der aber nur bei delete und update feuert. Die insert-Prozedur gibt die id des neuen Datensatzes zurück, mit der dann eine select-Prozedur ausgeführt wird.

    Leider kommt es in gelegentlich nach dem Speichern eines neuen Datensatzes  vor, dass die select-Prozedur eine unerwartete Ausnahme liefert. "An der Postition 0 befindet sich keine Zeile." Also der select mit der neuen Id liefert kein Ergebnis. Wenn ich die Ansicht dann 2 Sekunden später aktualisiere ist, der neue Datensatz da.

    Woran liegt das? Die Tabelle hat nicht einmal 10 Spalten. Kenn hier jemand im Forum diesen Effekt und was könnte ich dagegen tun?

    Vielen Dank für die Hilfe!

    ELM

     

    Freitag, 31. Mai 2013 08:10

Antworten

  • Hallo Forum,

    jetzt, wo ich mir die Mühe mache und den Code für das Posting formatiere, faällt mir doch glatt die Ursache auf. Im SELECT ist die WHERE Einschränkung

    E.gueltigVon < CURRENT_TIMESTAMP

    das Problem. Wird der Aufruf schnell nach dem Insert ausgeführt, ist diese Bedingung nicht erfüllt. <= löst das Problem.
    Sorry, wir haben echt schon ne ganze Weile gesucht, bevor wir hier um Hilfe gebeten haben.

    Danke euch, Frank

    Dienstag, 4. Juni 2013 10:41

Alle Antworten

  • Hallo,

    ein Select kann nicht schneller als ein Insert sein. Da dürfte etwas mit Deinem Code nicht stimmen.

    Nur lässt sich dazu nichts sagen, da wir weder die Prozeduren noch den Client-Code (welche Umgebung?) kennen. Es wäre nett, wenn Du das präzisieren würdest.

    Gruß Elmar

    Freitag, 31. Mai 2013 08:40
    Beantworter
  • Also der Client speichert bzw. ruft über den Server die insert-Prozedur auf der Datenbank auf.

    Wenn alles richtig läuft geht es so weiter: Der neuen Daten werden durhc die Prozedur in die Tabelle eingetragen und die ID des neuen Datensatzes wird an den Client zurückgegeben. Dann erfolgt mit dieser Id der Aufruf einer Select-Prozedur. Um den schicken neuen Datensatz anzuzeigen.

    Ich bin hier DB-Entwicklerin. Gearbeitet wird mit SQL Server 2008 und die Software wird mit C# entwickelt. Die Fehlermeldung kommt aus der Software, also C# und nicht von der Datenbank. Ich bin nicht so gut im Texte schreiben, sorry wenn das alles etwas verwirrt klingt.

    Freitag, 31. Mai 2013 08:53
  • Hallo,

    ich habe vor 15 Minuten eine Antwort geschrieben, aber anscheinend muss diese erst geprüft werden. Ich bin erst seit heute hier angemeldet. Wie lange dauert so eine Prüfung eines Beitrags?

    Am Besten ich formuliere mein Antwort nochmal neu.

    Ich bin Datenbankentwicklerin und hab es nicht so mit dem Schreiben von Texten. Wir arbeiten hier mit MS SQL Server 2008 und die Software wird mit C# entwickelt. Ich hab das oben etwas falsch beschrieben. Die Fehlermeldung kommt aus C#.

    Der Client ruft über den Server die Insert-Prozedur auf Datenbank auf, welche nach dem Insert die Id des neu angelegten Datensatzes zurückgibt. Mit der dann die Select-Prozedur aufgerufen werden sollte um den neuen Datensatz in der Software anzeigen zu können. Und da ist irgendwo der Fehler anscheinend wird die Prozedur manchmal ohne die neue Id aufgerufen und lieft die oben beschriebene Fehlermeldung.

    Gruß

    ELM

    Freitag, 31. Mai 2013 09:10
  • Hi,

    Ich rate mal...
    Ich nehme ihr gebt den aktuellen Wert des Identity Fields zurück, aber was verwendet Ihr da?

    Select @@Identity, oder SELECT SCOPE_IDENTITY();

    Wenn Ihr Trigger habt wollt Ihr eigentlich letzteres...

    HTH,

    Berndt

    Freitag, 31. Mai 2013 14:31
  • Hi,

    Ich rate mal...
    Ich nehme ihr gebt den aktuellen Wert des Identity Fields zurück, aber was verwendet Ihr da?

    Select @@Identity, oder SELECT SCOPE_IDENTITY();

    Wenn Ihr Trigger habt wollt Ihr eigentlich letzteres...

    HTH,

    Berndt

    Hallo Berndt,

    das ist so - pauschal - nicht richtig. @@IDENTITY "kann" man verwenden, wenn nicht innerhalb des Triggers weitere Relationen mit IDENTITY-Attributen mit Werten befüllt werden.

    Nur in diesem Fall verändert sich der Scope und ein falscher Wert für IDENTITY könnte zurückgegeben werden!

    Ohne die SQL-Statements, Trigger und Relation zu sehen ist das alles eher "Glaskugel lesen"
    Im aktuellen Kontext hat Elmar bereits alles geschrieben - diese Situation kann es bei SQL Server nicht geben (READ schneller als INSERT!)


    Uwe Ricken

    MCM SQL Server 2008
    MCSE - SQL Server 2012
    MCSA - SQL Server 2012

    db Berater GmbH
    http://www-db-berater.de
    SQL Server Blog (german only)

    Freitag, 31. Mai 2013 17:26
  • Hallo ELM,

    ich habe gerade im Mail-Eingang eine Benachrichtigung von Dir gefunden.

    Leider wurde Dein Beitrag als SPAM markiert und gelöscht. Ich habe eine Diskussion eröffnet, in der ich das fehlerhafte Verhalten angemant und um Korrektur gebeten habe.

    Relevanter Ausschnitt Deiner Antwort (hoffentlich übersteht sie die Prüfung ;):

    Wir arbeiten hier mit MS SQL Server 2008 und die Software wird mit C# entwickelt. ... Die Fehlermeldung kommt aus C#.

    Der Client ruft über den Server die Insert-Prozedur auf Datenbank auf, welche nach dem Insert die Id des neu angelegten Datensatzes zurückgibt. Mit der dann die Select-Prozedur aufgerufen werden sollte um den neuen Datensatz in der Software anzeigen zu können. Und da ist irgendwo der Fehler anscheinend wird die Prozedur manchmal ohne die neue Id aufgerufen und lieft die oben beschriebene Fehlermeldung.

    Der Fehler auf C# Seite dürfte auf eine fehlende Rückgabe eines ExecuteReaders zurückzuführen sein, und insoweit mehr nur ein Symptom.

    Hilfreich wäre der Aufbau Prozeduren (ggf. gekürzt) - vor allem der Insert Prozedur - erkennen sollte man:

    Wie erfolgt die Rückgabe des neuen Wertes
    und wie geht die Prozedur mit Fehlern um, wenn das Einfügen fehlschlägt.

    Gruß Elmar


    Freitag, 31. Mai 2013 17:28
    Beantworter
  • Hallo ELM und die restlichen Threadteilnehmer,

    was mir seit einiger Zeit auffällt (erstmals vor 10 Jahren oder so^^, allerdings auch nicht immer) ist, dass bei einem INSERT Statement, welches Parameter enthält, per <Command>.ExecuteNonQuery() abgesetzt und bei dem anschließend SELECT SCOPE_IDENTITY() zum auslesen des neuen IDENTITY Werts ausgeführt wird, es dazu kommt, dass NULL zurückgegeben wird. Dabei wird natürlich dieselbe, unveränderte und weiterhin geöffnete Connection verwendet. Es spielt auch keine Rolle, ob es mit demselben Command Objekt oder einem neuen, welches die gleiche, weiterhin geöffnete Verbindung nutzt gemacht wird.

    Ausmachen konnte ich den "Übeltäter" darin, dass beim Absetzen eines Statements mit Parametern vom SQL Server bzw. ADO.NET intern ein dynamisches SQL Statement erzeugt wird, welches per sp_executesql ausgeführt wird und damit in einer eigenen Sitzung läuft. Sehen kann man das über den SQL Server Profiler.

    Da das auch alte Classic ASP Anwendungen betraf und sowohl die als auch die .NET Anwendungen vorher jahrelang wunderbar ihren Dienst versehen haben, denke ich mal, dass irgendein Update für die verschiedenen SQL Server Versionen (betraf bei mir dann mittlerweile SQL Server 2000, 2008 und 2008 R2) hier etwas geändert hat.

    Lösung war dann, SELECT SCOPE_IDENTITY() nicht mehr getrennt ausführen zu lassen, sondern das direkt hinter das INSERT Statement zu hängen.

    Dim SqlStatement As String
        SqlStatement = "INSERT INTO Tabelle( Spalte1, Spalte2 ) VALUES( @Wert1, @Wert2 )"
    
    Dim SqlCommand As New SqlCommand( SqlStatement, SqlConnection )
        SqlCommand.Parameters.AddWithValue( "@Wert1", "Hallo" )
        SqlCommand.Parameters.AddWithValue( "@Wert2", "Welt" )
    
    Dim NewId As Int64
    
        ' --- Add SCOPE_IDENTITY selection because parametrized commands
        ' --- will be executed in sp_executesql statements
        SqlCommand.CommandText &= ";SELECT SCOPE_IDENTITY();"
    
        ' --- Execute insert statement and get identity value
        Result = Helper.CheckForInt64( SqlCommand.ExecuteScalar() )

    Ich hätte ja nichts dagegen, wenn das schon immer so gewesen wäre. Aber Anwendungen, die jahrelang liefen und die dann plötzlich Fehler hervorbringen, ließen einen dann doch ein wenig zweifeln.

    Da sp_executesql nur verwendet wird, wenn ein Statement mit Parametern ausgeführt wird, merken viele das zuerst gar nicht, wenn Sie bspw. die INSERT Statements als String, der die Werte schon beinhaltet, absetzen. Da geht das mit dem separat ausgeführten SCOPE_IDENTITY nämlich.

    Ich weiß nicht, ob es irgendwo dokumentiert ist. Falls ja, hab ichs damals nicht gefunden und heute ist das angehängte SELECT SCOPE_IDENTITY() bei mir automatisch in meinem O/R Mapper drin.

    Evtl. hilfts dir ja.


    Gruß, Stefan
    Microsoft MVP - Visual Developer ASP/ASP.NET
    http://www.asp-solutions.de/ - Consulting, Development
    http://www.aspnetzone.de/ - ASP.NET Zone, die ASP.NET Community



    Freitag, 31. Mai 2013 17:59
    Moderator
  • Hallo Stefan,

    das verwenden von sp_executesql bei parametrisierten Befehlen ist nicht neu, sondern existiert seit .NET 1.1 - nur .NET 1.0 machte es anfangs noch anders; wie weiß ich aber auch nicht mehr ;)

    Bewusst sollte man sich sein, dass ein SELECT SCOPE_IDENTITY() den letzten Wert der Sitzung liefert. Im übrigen empfiehlt sich ein CAST, da ansonsten Decimal(38,0) - max. für numerische Spalten - verwendet wird. Als Beispiele (für ELM):

    USE tempdb; CREATE TABLE Tabelle (id int IDENTITY(1,1) NOT NULL, Daten nvarchar(10) NOT NULL); GO INSERT INTO dbo.Tabelle (Daten) VALUES ('abc'); SELECT CAST(SCOPE_IDENTITY() AS int) AS id; GO -- vorheriger Wert INSERT INTO dbo.Tabelle (Daten) VALUES (null); SELECT CAST(SCOPE_IDENTITY() AS int) AS id; GO BEGIN TRY INSERT INTO dbo.Tabelle (Daten) VALUES (null); SELECT CAST(SCOPE_IDENTITY() AS int) AS id; END TRY BEGIN CATCH -- NULL oder aber Fehlermeldung SELECT CAST(NULL AS int) AS id; END CATCH; GO -- Abbruch via XACT_ABORT
    SET XACT_ABORT ON;
    SELECT 'XACT_ABORT ON';
    GO INSERT INTO dbo.Tabelle (Daten) VALUES (null); SELECT CAST(SCOPE_IDENTITY() AS int) AS id; GO

    Der zweite Befehl schlägt fehl, aber da die Ausführung nicht abgebrochen wird, wird der Wert des erfolgreichen Vorgänger geliefert. Was in Verbindung mit .NET zum Problem wird, wenn man die ausgelöste Ausnahme "schluckt" und weiter macht.

    Die dritte Variante verwendet ein BEGIN TRY (ab SQL Server 2005) - was man um Transaktionen ergänzen kann.

    Die letzte Variante verwendet  SET XACT_ABORT ON, womit man die Ausführung abbrechen kann, ausführlicher von Dan Guzman: Use Caution with Explicit Transactions in Stored Procedures

    Gruß Elmar

    Freitag, 31. Mai 2013 18:27
    Beantworter
  • Hallo Elmar,

    1.1 würde ja in etwa mit 2003 (ungefähr da ist mir das zum ersten mal aufgefallen) zusammenpassen. Ich weiß aber auch, dass es mit .NET 2.0 stellenweise problemlos lief, da ich 2005 eine neue Anwendung geschrieben habe, bei der ich das anfangs nicht brauchte (und auch nicht so gemacht habe). Erst zu einem späteren Zeitpunkt gab es da Probleme und ich hab das dann generell umgestellt.

    Ich will aber nochmal erwähnen, dass das Problem "irgendwann" (wann weiß ich wirklich nicht mehr) auch alte Classic ASP Anwendungen betraf, die mit Classic ADO und INSERT Statements ohne Parameter, ausgeführt per <Connection>.Execute <SqlStatement> und anschließendem OpenRecordset zum Auslesen des neuen Werts arbeiteten. Allerdings muss ich gestehen, dass mir nicht mehr wirklich geläufig ist, was ich damals zur Behebung unternommen habe. Bei einigen Anwendungen wohl auch das SELECT Statement angehangen, bei anderen ...


    Gruß, Stefan
    Microsoft MVP - Visual Developer ASP/ASP.NET
    http://www.asp-solutions.de/ - Consulting, Development
    http://www.aspnetzone.de/ - ASP.NET Zone, die ASP.NET Community

    Freitag, 31. Mai 2013 20:19
    Moderator
  • Hallo Stefan,

    dann könnte das hinkommen. Damals (vor zehn Jahren, noch SQL Server 2000) wurde einiges geändert, so der Einsatz von sp_resetconnection in Verbindung mit dem Connection Pooling (auch  ODBC / Ole Db  / MDAC). Wobei ich für die Einzelheiten erst in meinen Archiven buddeln müsste.

    Aber bevor wir das vertiefen und evtl. Verwirrung stiften:
    Wenn ELM wie geschrieben Prozeduren einsetzt, kann das nicht zum Problem werden. Dabei funktioniert SCOPE_IDENTITY wie erwartet / dokumentiert, da man sich im gleichen Kontext bewegt.

    Gruß Elmar

    Freitag, 31. Mai 2013 20:48
    Beantworter
  • Hallo Elmar,

    da hast Du recht. Und ich denke, das Problem von damals ist schon soooooooooo alt, da lohnt es sich jetzt nicht mehr, die Archive zu durchforsten.

    Wenn ELM sich nochmal detaillierter dazu äußern könnte, wäre das sicher hilfreich für die weitere Lösungssuche.

    @ELM: Die Fehlermeldung an sich kommt wahrscheinlich daher, dass Du keine Prüfung auf das Vorhandensein eines Datensatzes in der Rückgabe vornimmst. Poste doch mal bitte den konkreten C# Code zum Auslesen und markiere die Zeile, die den Fehler verursacht.

    Die SQL Prozeduren wären auch hilfreich.


    Gruß, Stefan
    Microsoft MVP - Visual Developer ASP/ASP.NET
    http://www.asp-solutions.de/ - Consulting, Development
    http://www.aspnetzone.de/ - ASP.NET Zone, die ASP.NET Community

    Freitag, 31. Mai 2013 21:16
    Moderator
  • Hallo Forum,

    ich übernehme den Thread von meiner Kollegin E_L_M, da sie scheinbar Probleme mit ihrem Account hat.

    Ok, hier also die technischen Fakten zum Problem in komprimierter Form.

    Die Software ist in klassischer Dreischicht-Architektur ausgeführt.

    1. Ein C# Client greift per .Net Remoting auf einen C# Anwendungsserver zu.
    2. Der C# Anwendungsserver greift per ADO.NET auf eine SQL Server 2008 R2 Datenbank zu.

    Im beschriebenen Problemfall wird folgender Codeflow durchlaufen

    1. Der Client erstellt einen neuen Datensatz in einer DataTable. Deren Feld [ID] ist Identitätsspalte mit AutoIncrement, Seed -1, Step -1, damit es nicht zu Kollisionen mit vorhandenen Datensätzen kommt.
    2. Der Datensatz wird zum Speichern per RPC (Remote Procedure Call) an den Anwendungsserver geschickt. Rückgabewert des Aufrufs ist ie vom SQL Server vergebene echte ID für den Datensatz (int).
    3. Der Anwendungsserver erzeugt einen SqlCommand mit einer SqlConnection und einer SqlTransaction. Einer der SqlCommanParameter ist @Id mit Direction InputOutput
    4. Der Anwendungsserver feuert den SqlCommand per ExecuteNonQuery innerhalb der Transaction an den SqlServer. Die Rückgabe des Aufrufs (betroffene Datensätze) wird ausgewertet
    5. Der SqlServer erstellt den Datensatz per INSERT
    6. Ein Trigger kommt hier (beim Insert) nicht zum Zuge
    7. Der SQL Server selektiert die neue Id des eingefügten Datensatzes per SCOPE_IDENTITIY()
    8. Der Anwendungsserver prüft, ob mindestens 1 als Rückgabe von ExecuteNonQuery gesetzt wird und liest die neue ID aus dem entsprechenden SqlCommandParameter
    9. Der Anwendungsserver gibt die neue ID als Ergebnis des RPC an den Client zurück. BTW: die Transaktion wird immer korrekt committed oder zurückgerollt.
    10. Der Client ruft nun ohne Verzögerung die Daten mittels der aus dem vorigen Aufruf erhaltenen ID komplett per RPC an den Anwendungsserver ab. Rückgabe der Remote Procedure ist ein DataSet mit den frischen Daten (inkl related Tables).
    11. Der Anwendungsserver ruft per SqlCommand und SqlConnection OHNE SqlTransaction die Daten vom SqlServer ab, indem SqlCommand.ExecuteReader und DataTable.Load(reader) ausgeführt wird.
    12. Der Client versucht nun, die erste Zeile in der zurück gelieferten DataSet.DataTable zu lesen. Sporadisch ist diese Zeile leer, weil keine Daten zurück geliefert wurden. Daher der Fehler "An Position 0 befindet sich keine Zeile".

    Wichtige Infos:

    1. die Aufrufkette schlägt nur sporadisch fehl. Der Fehler ist auch nicht deterministisch, was das Forschen nach der Ursache zusätzlich erschwert.
    2. Bis zum Punkt 9 funktioniert das Ganze immer. Die Daten sind immer in der Datenbank und am Client kommt immer eine korrekte Id aus demRPC zurück.

    Hier noch etwas Code

    1. Clientaufruf von Speichern und Lesen am Anwendungsserver (die Aufrufe erfolgen in dieser Form, die Syntax wurde etwas verfremdet)
      var
       id = ServiceContainer.GetService<IRemoteXX>().GetRemoteObject<Ixx>
      ().Speichere(_data);
      _data = 
      ServiceContainer.GetService<IRemoteXX>().GetRemoteObject<Ixx>().Hole(id);
    2. Server Aufruf Speichern (verkürzt)
      using (var connection = ServiceContainer.GetService<Ixx>().GetConnection())
      {
      using (var transaction = connection.BeginTransaction())
      {
      using (var command = connection.CreateCommand())
      {

      command.CommandType = CommandType.StoredProcedure;
      command.Transaction = transaction;
      command.CommandText = 
      "[xx].[insert_xx]";
      var idOutputParam = command.Parameters.AddWithValue("@id", id); idOutputParam.Direction = ParameterDirection.InputOutput;
      command.Parameters.AddWithValue(
      "@txx", transaktionsid_neu);
      affectedRows = command.ExecuteNonQuery();
      id = (
      int)idOutputParam.Value;
    3. Server Aufruf Select (verkürzt)
      using
       (var connection = ServiceContainer.GetService<ISqlAccess>().GetConnection())
      {
      using (var command = new SqlCommand("[xx].[select_Exx", connection))
      {
      command.CommandType = CommandType.StoredProcedure;
      command.Parameters.AddWithValue("@exx", id);  using (var reader = command.ExecuteReader())
      {
      dataSet.Exx.Load(reader);

      }

    Uns fehlt leider das Know-How, wie der Sql Server intern seine Aufrufe abarbeitet, daher wissen wir nicht, wo wir das Problem lokalisieren sollen.

    TIA

    Montag, 3. Juni 2013 09:43
  • hallo TIA

    lies mal diesen KB Artikel und ueberpruef ob Eures Problem nicht darauf zurueckzufuehren ist.

    You may receive incorrect values when using SCOPE_IDENTITY() and @@IDENTITY


    Please use Mark as Answer if my post solved your problem and use Vote As Helpful if a post was useful.

    Montag, 3. Juni 2013 15:22
  • Hi Daniel,

    danke für deine Antwort.
    Das passt nicht zum Problem. Die Id wird ja korrekt zurück gegeben. Wenn ich im nachfolgenden SELECT eine künstliche Verzögerung einbaue, funktioniert der Aufruf korrekt.

    PS: TIA sollte übrigens für Thanks In Andvance stehen :). Sorry.

    Grüße Frank

    Dienstag, 4. Juni 2013 05:34
  • Hallo Forum,

    ich hab das Ganze jetzt auf unsere SQL Server Datenbank reduziert.

    Wenn ich per Script erst unsere INSERT Prozedur und danach direkt die SELECT Prozedur aufrufe, bekomme ich in ca 90% der Aufrufe den gerade eingefügten Datensatz NICHT zurück.

    DECLARE	@return_value int,
    		@id int = -1
    
    EXEC	@return_value = [dbo].[insert_X]
    		@id = @id OUTPUT,
    		@Name = N'eins',
    		@Bemerkung=null,
    		@beginn = N'01.01.2013',
    		@ende = null,
    		@status = 10,
    		@transaktion = 1
    
    SELECT	@id as N'@id'
    
    EXEC [dbo].[select_X] @xid=@id

    Hier die beiden Procs.

    CREATE PROCEDURE [dbo].[insert_X]
        (
          @id					INT OUT ,
          @Name	VARCHAR(250) ,
          @bemerkung			VARCHAR(250) ,
    	  @beginn				datetime,
    	  @ende					datetime, 
          @status				INT ,
          @transaktion			INT
        )
    AS
        BEGIN
            INSERT  INTO dbo.X
    					   ( Name,
    						 bemerkung,
    						 beginn,
    						 ende,
    						 status,					 transaktion)
            VALUES  ( @Name ,
                      @bemerkung ,
    				  @beginn,
    				  @ende,
                      @status ,
                      @transaktion 
                    )          
    
            IF @@error != 0
                OR @@rowcount != 1 
                BEGIN
                    RETURN 999 ;
                END
            ELSE 
                BEGIN
                    SELECT  @id = SCOPE_IDENTITY() ;
    
                    RETURN 0 ;
                END
        END
    CREATE PROCEDURE [dbo].[select_X]
      @Id INT = -1
    AS
    BEGIN
      SET NOCOUNT ON      
      SELECT E.id,
             E.Name ,
             E.bemerkung ,
    		 E.beginn,
    		 E.ende,
             E.status, 
    		 E.transaktion,
            S.Loginname As LetzterBearbeiter,
            S.ID As LetzterBearbeiterID,
            T.zeitpunkt As LetzterBearbeitungsZeitpunkt
            FROM 
    		dbo.X AS E
    		LEFT JOIN dbo.Transaktion As T    On E.Transaktion=T.ID 
            LEFT JOIN dbo.SicherheitsSubjekt As S On T.Benutzer = S.ID
        WHERE     E.id = @Id AND E.status != 15
         AND ( E.gueltigVon < CURRENT_TIMESTAMP ) AND ( E.gueltigBis >= CURRENT_TIMESTAMP  OR E.gueltigBis IS NULL );
         
         return 0;
    END
    

    Wir hatten das Problem vorher noch nie. Das Verhalten lässt aich aber auf verschiedenen SQL Servern (2008 R2) nachvollziehen. Hat keiner eine Idee?

    Grüße, Frank

    Dienstag, 4. Juni 2013 10:33
  • Hallo Forum,

    jetzt, wo ich mir die Mühe mache und den Code für das Posting formatiere, faällt mir doch glatt die Ursache auf. Im SELECT ist die WHERE Einschränkung

    E.gueltigVon < CURRENT_TIMESTAMP

    das Problem. Wird der Aufruf schnell nach dem Insert ausgeführt, ist diese Bedingung nicht erfüllt. <= löst das Problem.
    Sorry, wir haben echt schon ne ganze Weile gesucht, bevor wir hier um Hilfe gebeten haben.

    Danke euch, Frank

    Dienstag, 4. Juni 2013 10:41