unser fatales Problem hat folgende technische Kennwerte

1. DB Server : MSSQL, Prof. Version
2. Delphi : XE2, ADO, x64
3. Datenbank : 10 Tabellen
4. Dateivolumen 800 Mbyte
5. Index Volumen 200 Mbyte
6. Anzahl der Datensätze in der Größten Tabelle ~ 3 Mio

Unsere Anwendung liefert ein Thread Fehler beim Einfügen von weiteren Datensätzen in die DB. Mit dem MS Datenbank Tool kann man die DB öffnen und manuelle Abfragen durchführen.
Client Hardware : WIN7 Prof, x64 , Speicher 16 Gbyte RAM (hier sollte kein Problem vorliegen)

die Größe stellt kein Problem dar und geht sogar mit MSSQL Express .....

Das Problem ist hier woanders zu suchen.

Wie lautet denn der Fehler genau ? ADO Meldung oder eine von Delphi ?

Zitat von bernhard_LA:

Unsere Anwendung liefert ein Thread Fehler beim Einfügen von weiteren Datensätzen in die DB.

Nur so aus Neugierde, welchen Fehler denn?

Gruß
K-H

Zitat:

... liefert ein Thread Fehler beim Einfügen von weiteren Datensätzen in die DB

Daten Abfragen geht also? Performance OK oder läuft die Abfrage ggf. ins Query Timeout?
Ist ein Insert über das SQL-Managementstudio oder andere DB Tools möglich oder kommt dort auch ein Fehler?
Wie sieht das Zeitverhalten aus, wenn eure Anwendung versucht Datensätze einzufügen?

mit diesem kleinen Testprogramm können wir den Fehler aus der richtigen Anwendung nachbilden :

zusammenfalten · markieren

Delphi-Quellcode:

unit Unit_openADOTable;

interface

uses
  Winapi.Windows, Winapi.Messages, System.SysUtils, System.Variants, System.Classes, Vcl.Graphics,
  Vcl.Controls, Vcl.Forms, Vcl.Dialogs, Vcl.StdCtrls, Data.DB, Vcl.ExtCtrls,
  Vcl.Grids, Vcl.DBGrids, Data.Win.ADODB;

type
  TForm1 = class(TForm)
    ADOTable1: TADOTable;
    ADOConnection1: TADOConnection;
    DBGrid1: TDBGrid;
    Panel1: TPanel;
    DataSource1: TDataSource;
    Button1: TButton;
    procedure Button1Click(Sender: TObject);
  private
    { Private-Deklarationen }
  public
    { Public-Deklarationen }
  end;

var
  Form1: TForm1;

implementation

{$R *.dfm}

procedure TForm1.Button1Click(Sender: TObject);
var Servername, Databasename, TableName : String;
    DatabaseStr: String;
begin

  Servername := 'mssql_server';
  Databasename := 'databasename';


  ADOConnection1.Connected := False;

  ADOConnection1.LoginPrompt := false;

  DatabaseStr :=
    'Provider=SQLOLEDB.1;Integrated Security=SSPI;Persist Security Info=False;Data Source='
    + Servername + ';Initial Catalog=' + Databasename + ';';
  ADOConnection1.ConnectionString := DatabaseStr;

  ADOConnection1.Connected := True;

  ADOTable1.Active := true;
end;

end.

Ich würde mal Serverseitig nachschauen ob es eine Fehlermeldung gab. (Logdateien o.ä.)

Hast du da ein nvarchar Feld in der Tabelle mit mehr als 127 Zeichen?

http://stackoverflow.com/questions/1...22561#14222561

Kannst du nicht per ADO mit dem Native Client zugreifen?
siehe auch hier: http://msdn.microsoft.com/de-de/library/ms130978.aspx

Wie wäre es mit

markieren

Delphi-Quellcode:

ADOConnection1.Connected := True;
ADOTable1.Active := false;
ADOTable1.Active := true;

@Sir Rufo
dieser Multistep-murks wird auch durch Abfragen verursacht:

markieren

Code:

Select 'Ich habe '||count(Database5.Tablell234.id_vondengeschlossenendatensaetzen)||' Datensätze in meiner DB und noch ein paar Zeichen mehr'

Wenn man den Feldnamen verkürzen kann, hat man eine chance, daß es funktioniert.


Gruß
K-H

Zitat von bernhard_LA:

  ADOTable1.Active := true;

Muss man denn unbedingt eine Table-Komponente mit 3 Mio Datensätzen öffnen können?
Wie wärs mit einer Query?
MaxRecords steht auf 0?
Filter gesetzt?

Gerade für Insert eher keine Table-Komponente nehmen?
Am besten nie eine Table-Komponente nehmen.

Zitat von jobo:

Zitat von bernhard_LA:

  ADOTable1.Active := true;

Muss man denn unbedingt eine Table-Komponente mit 3 Mio Datensätzen öffnen können?
Wie wärs mit einer Query?
MaxRecords steht auf 0?
Filter gesetzt?

Gerade für Insert eher keine Table-Komponente nehmen?
Am besten nie eine Table-Komponente nehmen.

Recht hast Du,
aber in allen Beispielen, die ich gesehen habe, wird fröhlich mit Tables und Datasets herum gespielt.
wahrscheinlich wissen die wenigsten welche Möglichkeiten eine Query beinhalted.

Aber das Nutzen einer Query wird sein Problem ja nicht lösen sondern nur umgehen.

Gruß
K-H