I'm using Linq to SQL with SQL 2005. I'm parsing a large fixed width file and importing the data into SQL via custom entities that I have mapped to the database using property attributes.
The program runs for about 240 records before throwing this error. I've checked the columns (all four of them) and the data it's trying to put in and it shouldn't be throwing this error. I've even gone so far as to change the columns from varchar to text, and it still throws the error. When I manually insert the same values, they insert fine.
Is there a known bug or anything in Linq to SQL? I'm calling context.submitall() on every loop to insert. I've read that .NET 3.5 SP1 gives better error messages from SQL, but I'm still not seeing anything.
Thanks for any help.
Is it possible that you've changed your schema since you built the Linq to SQL classes? The designer entities won't be updated when you change your SQL schema unless you delete/recreate the class in the designer or hand-edit the properties for the designer-generated class. I know that it keeps track of the column width for string (varchar) columns in the class -- though I don't know if it actually checks it before submitting or just keeps it as a reference for any validation that you would do. I have seen similar problems with things like autogenerated ids, though, that were solved by updating the class in the designer.
Well, I found the bug, and it was definitely not a problem with Linq or with SQL. I was chopping up and changing properties on another object, not realizing that it was now attached to SQL via Linq, and it was that object throwing the errors.
Lesson learned: Do not alter properties directly on an object unless you really want to change them, and especially if it's attached to the data context.
Related
Yes, it's 2021 and I am still using DataSets! But, it still works mostly ...
However, I am having an issue that is slowly driving me crazy. I have several projects using PostgreSQL database and DataSets. The issue causing me grief is that while using MS SQL Server databases, tables with identity keys have no issues in updating the DataTable and returning the keys following the update. With postgres, we need to add a RETURNING id statement at the end of the INSERT query or use a SELECT currval(). Which by itself is fine. But, if you then edit the DataTable in any fashion (add a query to it for example), it trumps the insert query and turfs the parameter provided to handle the return value.
Is there any known way around this, or am I missing something simple? For the previous 20 years I worked almost exclusively with MS SQL Server and it just works ...
Thanks in advance!
My application will be querying a database using Entity Framework. The problem is that the database table structure changes fairly often (a few times a year).
Back in the SQL days, we would store SQL queries in Resource files (.resx) and when any database changes occurred, we could just edit the one resource file and not have to edit any code in the app, recompile, etc.
Are there any good ways to do this with Linq-to-SQL?
Linq2SQL is innately code-based. If your schema is going to change, then the code will need to change.
The only way I can see around this, and still get some of the benefits of linq, is to write everything as Stored Procedures, which you can than add as method to the linq DataContext.
Then, as long as the Name, input parameters and output columns remain the same, you can change what the SP is doing on the database and the code can stay the same.
I have to change the data source in quite a few reports. Its easy when the original data source uses table, but its more complicated when instead has a SQL command (well, practically its a view but made in the report, not in the original database).
Lets say that report has originally such command:
SELECT nbr FROM equipment WHERE equipment.owner='ABC'
I know that in the new database Equipment.nbr is called now Items.ID, so I can easily map this. But what about the rest of command, the "WHERE" part? In the new database there is obviously no Equipment.owner and possibly might not even be Items.owner. Does crystal simply drop this part? I know how to remake it, by simply adding selection formula to the report, but first I have to be know what happened to the "WHERE" condition, and after such mapping I can't anymore preview the SQL command in the data source.
Confrim me where you are using this query.
If it is in Data soruce then no issue this report will work.
If it is in formula then I have doubt crystal report won't accept this format even in basic syntax mode.
I am currently using entity framework (.net 4) to read from a 3rd party database using LINQ statements. Unfortunately, at compile time i do not know from which table i will be reading - in fact, new tables can be added to this database after my application is compiled. The table name to read from will be passed as a string parameter to my method.
How should one approach this situation when the table name is not know at compile time? i cannot even add these tables to my data model since they might not yet exist. whilst i like the convenience of linq, i am after a simple approach.
thanks!
For the queries that can only be constructed at run-time and that will return types of different shapes, you're pretty much forced to craft and execute the SQL you want to run yourself. DataContext.ExecuteQuery(string query, params object[] parameters) is going to be your friend.
You probably would already do this, but I would recommend keeping this portion of code isolated to one section of the code, where you execute the query, and then put the results into an strongly typed object before exposing it to other area's of your application. Make sure you clean the table name too.
I have a WebObjects app, Openbase db, and I'm getting a never before seen exception when doing a raw rows (non ORM) query during a batch operation. It looks like the jdbc adaptor is throwing on a date value in the db and is unable to coerce the raw data into the proper type. It literally kills the app and ends the export process. Here's the top two relevant lines from the trace:
java.lang.IllegalArgumentException
at java.sql.Date.valueOf(Date.java:138)
at com.openbase.jdbc.f.getDate(Unknown Source)
I've tried changing the column type from date, to datetime to timestamp, and adjusting the eo model accordingly, but the exception remains. I'm wondering what I can do to resolve this, specifically if anybody knows a more sophisticated query mechanism I can employ to identify the possibly bad rows? Openbase's documentation is pretty sparse, and I'm hoping maybe somebody knows how to use patterns to identify possible bad values using openbase sql. Or, some other means of identifying the issue. Thanks.
Turns out the problem was due to a version mismatch between the Openbase version and the java version. Unfortunately, I had no choice but to rewrite the dump routine to use the bulk save openbase function, and then parse out the resulting csv. Interestingly, the same dates that were causing problems printed just fine, which enabled saving a lot more rows. Summary: stick with the open source db's; unless you're going high end, there's no advantage to solutions like Openbase anymore.