I have a database in SQL Server with a single table in it. This ends up receiving information from a service. The data coming in is essentially a flat file (it's just a CSV packed into a JSON field) that gets directly imported into the existing table. That incoming data has no PK. At some point in the past, a PK field was added to the destination table. From looking at the data, it is clear that people changed their minds a few times. Some of the records are GUIDs, then for a time it was some concatenated string made up of a few fields from the table...and maybe the current date. Then it went back to GUIDs.
Therefore, the PK field is not a uniqueidentifier field, it's a varchar field. That's life.
My original attempt was to suck the CSV flat file into a datatable, then push that to the DB table using a command builder. That almost worked, but not quite. The CSV flat file lacks the PK field.
My first thought was to add the PK field to the datatable prior to pushing the DT to the DB, but that doesn't work, because filling in the PK field means that the rowstates are set to Modified, and I need them set to Added, since these are all new rows.
I then thought I might leave out the PK field entirely and put a default value for the row into the table in the DB. That might work, but only if I write out ALL the fields in this monster table. Otherwise, the source table has not field with the name of the PK field, so the CommandBuilder fails, since I built the commandBuilder using "SELECT * FROM DestinationTable". Naturally, that has the PK field.
If I try to add the PK field to the source table in the query that fills the source table, that also doesn't work, because it puts in a field.
The only thing that seems like it would work is to write out every single field for the CommandBuilder Select query, and there are a LOT of them. Worse, I can't guarantee that the set won't change.
Is there a better way to do this?
There are 63 columns in the DT. When I wrote them out, the Update on the dataadapter fails with a message saying that it can't insert Null into the PK field. The PK field was left out because I thought it would be sufficient to set a DefaultValue in the DB table to NewID(). That doesn't appear to work, and I'm not sure why.
What I know I can do is to write out a horrific INSERT query for the DA, but with 63 fields, about half of which follow a stupid naming convention that requires square brackets....Arrrrrggghhhh!
Therefore, the PK field is not a uniqueidentifier field, it's a varchar field. That's life.
My original attempt was to suck the CSV flat file into a datatable, then push that to the DB table using a command builder. That almost worked, but not quite. The CSV flat file lacks the PK field.
My first thought was to add the PK field to the datatable prior to pushing the DT to the DB, but that doesn't work, because filling in the PK field means that the rowstates are set to Modified, and I need them set to Added, since these are all new rows.
I then thought I might leave out the PK field entirely and put a default value for the row into the table in the DB. That might work, but only if I write out ALL the fields in this monster table. Otherwise, the source table has not field with the name of the PK field, so the CommandBuilder fails, since I built the commandBuilder using "SELECT * FROM DestinationTable". Naturally, that has the PK field.
If I try to add the PK field to the source table in the query that fills the source table, that also doesn't work, because it puts in a field.
The only thing that seems like it would work is to write out every single field for the CommandBuilder Select query, and there are a LOT of them. Worse, I can't guarantee that the set won't change.
Is there a better way to do this?
There are 63 columns in the DT. When I wrote them out, the Update on the dataadapter fails with a message saying that it can't insert Null into the PK field. The PK field was left out because I thought it would be sufficient to set a DefaultValue in the DB table to NewID(). That doesn't appear to work, and I'm not sure why.
What I know I can do is to write out a horrific INSERT query for the DA, but with 63 fields, about half of which follow a stupid naming convention that requires square brackets....Arrrrrggghhhh!