Question

我完全无法解释它。

使用.Net XSD作为数据集。 TableAdapter已在DataSet.cs中进行了扩展，以接受用于根据VS构建选项设置连接字符串的标记。使用BackGroundworker在单独的线程上执行写入。

应用程序将使用自定义类型将数据收集到内存中的队列中。数据收集后，队列的元素将加载到数据表中，当队列为空时，表将更新到后端。这通常在用户准备另一个数据收集会话时完成。在几秒钟内更新了数千行，性能良好。应用程序连接到要写入的MSSQL Express的本地实例。本地和远程编写都出现了这个问题。

除了不可预测的写入数据失败之外，这对于实现很有效。在处理50,500,500个或50000个元素之后可能会发生故障，并且似乎没有任何可识别的前提条件。在每种情况下，writecount都会注册一些WriteToDB（）调用，然后停止更新。队列中的数据实际上都没有写入DB，因为ta.Update（dt）;从来没有调用过。这让我相信线程正在被停止，但是测试表明它继续执行并且什么也没做。不确定问题是Thread，TableAdapter还是DataTable，但是出现问题并停止写入。

将零传递给ReportProgress方法，以便它可以与GUI交互并根据需要更新显示元素。我已经使用调试器检查了内存使用情况，但这并没有出现在机器可用内存附近的任何地方。我介绍（以后删除）ManualResetEvent来尝试管理线程以防止这种情况，但它没有解决问题。

有没有人经历过任何类似的行为？有人能提供解决这个问题的任何见解吗？

示例代码：

private TableAdapterNamespace.TableAdapter ta = null;
private Namespace.DataTable dt = null;
private Queue<CustomClass> Q = null;

public Constructor()
{
...
    ta = new TableAdapterNamespace.TableAdapter(prgMain.DB_CONNECT);
    dt = new Namespace.DataTable();
    Q = new Queue<CustomClass>(100000);
...
}

private void DBWriter_DoWork(object sender, DoWorkEventArgs e)
{
...
    if (Q.Count > 0)
    {
        WriteToDB(Q.Dequeue(), strsource);
        writecount += 1;
        BGWWriter.ReportProgress(0);
    }
    else
    {
        dt.EndLoadData();
        ta.Update(dt);
        BGWWriter.ReportProgress(0);
    }
...
}


private void WriteToDB(CustomClass bt, string strsource)
{
    dt.DataRow drn = DataTable.NewDataRow();
...
     drn.User = Environment.UserName;
     drn.ID = ID;
     drn.SessionStamp = bt.Stamp;
     dt.LoadDataRow(drn.ItemArray, System.Data.LoadOption.Upsert);
...
}

侵入性思维：这可能是由于队列被反复填充和清空造成的吗？

TableAdapter无法预测地停止写入DB

0 个答案: