Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CreateDataAdapter and DuckDbDataAdapter #68

Open
bnuzhouwei opened this issue Nov 17, 2022 · 4 comments
Open

CreateDataAdapter and DuckDbDataAdapter #68

bnuzhouwei opened this issue Nov 17, 2022 · 4 comments
Labels
ADO.NET ADO.NET feature parity

Comments

@bnuzhouwei
Copy link

There no DuckDbDataAdapter in the lib, can implement it?

@Giorgi Giorgi added the ADO.NET ADO.NET feature parity label Apr 26, 2023
@lloydchriswilson
Copy link

I have a database agnostic application that overrides System.Data.Common classes. It appears that several are missing like CommandBuilder and especially DataAdapter. Are there any plans to support these classes?

Thanks!

@Giorgi
Copy link
Owner

Giorgi commented Jun 17, 2024

No plans currently.

@lloydchriswilson
Copy link

I think it is not too hard. Using the SQLite library as a go-by (not copying) I confirmed several things and wrote DuckDBCommandBuilder and DuckDBDataAdapter. The latter appears to be trivial, but CommandBuilder is about 200 lines of verbose VB code (can be easily converted to C#). I am stuck because the DuckDBDataReader class has an overridden method called GetSchemaTable which does not really give the information that DBCommandBuilder needs to create insert, etc., commands. Specifically, the field lengths and key field info is not placed in the schema table. I think you'd have to parse the select command to get the table name and then run the Describe command to extract the information needed (or use some other API call).

I'm providing this information (and my work so far) in case you decide to try to finish the work yourself. I don't feel confident enough with the database to fix GetSchemaTable myself. It is great that you have lots of the standard ADO.Net classes working; just adding a couple more like CommandBuilder and DataAdapter would provide much better functionality. Most of the hard work is already done in the System.Data.Common classes (as you know).

One other thing: in DuckDB when you set a query parameter name, all other providers I use (SQLite, SQL Server, Oracle, MySQL, etc.) are forgiving if you include the SQL prefix when defining the parameters (e.g., you can pass $PARM1 as the parameter name) and it works OK, however DuckDB requires that the name exclude the prefix (e.g., PARM1). It was easy to fix my code, but you might want to consider this.

DuckDB.Net.Data.zip

@Giorgi
Copy link
Owner

Giorgi commented Jun 21, 2024

Thanks for investigation @lloydchriswilson. Can you send a PR for the parameter prefix issue?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ADO.NET ADO.NET feature parity
Projects
None yet
Development

No branches or pull requests

3 participants