I am using "System.Data.SQLite;". The Dll version is 1.0.103.0.
My sql statement is
ALTER TABLE main.[Resistors] RENAME [Manufacturer Part Number] to [Manufacturer Part Number 1];
The error message I get is
"Message=SQL logic error or missing database"
I have also tried
ALTER TABLE [Resistors] RENAME COLUMN [Manufacturer Part Number] to [Manufacturer Part Number 1];
Which returned "SQL logic error or missing database
near "COLUMN": syntax error"
and tried
ALTER TABLE main.[Resistors] RENAME COLUMN [Manufacturer Part Number] to [Manufacturer Part Number 1];
Which returned "SQL logic error or missing database
near "COLUMN": syntax error
I'm assuming I need to change "main." to something else but I don't know what it should be. Or I need to update my SQLite. I'm working on that.
Some of the versions of SQLite do not support renaming columns. Try updating the references available in your project. See this NuGet Filename. This version supports renaming columns.
System.Data.SQLite.1.0.116.0.nupkg
Related
I've been trying to create a function to load some files insert them into a temp table based on an existing table, then verifying that there are not duplicated rows on the files loaded and then inserting them into proper tables in the DB, tried using something like this:
let statement = " select * from ", vtable clipped, " where 1=0 into temp t_",vtable clipped
prepare pstatement from statement
execute pstatement
to no avail because the temp table seems to be created on a different session than the one im working in.
Any suggestions?
Thank you all beforehand
If you prepare and execute a statement as shown, it is created on the connection you're using at the time. If you don't mess with the connections (CONNECT, DISCONNECT, SET CONNECTION), then it should all be clean — if the statement worked at all. Are you checking errors (WHENEVER ERROR STOP, perhaps)? Or have you displayed statement to ensure the SQL is as expected (no untoward chopping of the string, for example — that could account for why the table appears to be missing).
Remember that a temporary table is private to the session. If you run a LOAD statement in the I4GL program, there should be no problem, but you can't use a separate loader program with a temporary table. In terms of the database, it would have to be a 'permanent' or 'regular' table, even if you remove it soon after creating it.
You could also prepare an explicit CREATE TEMP TABLE statement to create a table.
Also consider whether using an external table would help you with the loading. There are also violations tables that could be used to trap problematic rows while loading directly into the main table.
In informatica mapping design, there must be a target table, but in my design, I only use informatica to call store procedures, and after they were called, all work has been done, so I don't need a target table to be inserted or updated.
I used a non-exist table as the target table, and one nonsense field as the input port(cause there must be at least one input port!), then unchecked or the option(insert, update,delete) in the session configuration, so that the informatica would not generated DML SQL statements, avoiding "no table" errors.
But then informatica treat the input row as reject row and try to write it into a bad file. And cause I unchecked the insert option, the session log showed that there was an error that it couldn't be insert into the bad file!
Strangely, this error never showed in the monitor, and all session run successfully! It only appeared in informatica's meta table.
Is there a better way to avoid this problem, although it has no effect to my result? Is there a possibility to use a non-exist table and do nothing to it (include reject the input rows)?
Use a filter transformation just before the target and put filter condition 'FALSE'
No rows will go to the target
I had run into this same issue when i wanted to just execute a stored procedure and nothing else.
I solved this by creating a dummy source object that had one port and a dummy target with one port of the same datatype. In the source qualifier I added a SQL statement select 1 from dual (since it's Oracle).
I then added a filter object that was set to false. Then I connected the single port from the source/qualifier through the filter and finally to the target.
When the mapping is run, the source qualifier will return 1 row of one value, this will pass through to the filter but nothing will come out of the filter because the filter is set to false. This mapping will always be successful and valid because all ports are connected a nothing makes it to the "dummy" target thus no bad file logs or failure, etc.
Let me know if you need any clarification and I can update this answer.
No, you always need a target for the mapping to be valid. But I would rather work with a flat file target instead of a database table, you'll have much less work to do.
If you're on Linux / Unix, you can even route the file to /dev/null (use folder:/dev/, file:null) so the file is not actually written to the filesystem.
And using one dummy port is the right way. As you have said, you need at least one port, even if you don't really use it.
As odd as this may sound (Unix systems): neither source, nor target need to exist.
Source (flat file): /dev/null, column DUMMY
Target (flat file): /dev/null, column DUMMY
And you don't need to use any databases for the session to succeed, nor use any filters. It runs.
I'm using FileTable in SQL Server 2014 and EF code first in my project.
When I use this command
USE [master]
GO
ALTER DATABASE [OnlineStore]
SET FILESTREAM( DIRECTORY_NAME = N'OnlineStore',
NON_TRANSACTED_ACCESS = FULL) WITH NO_WAIT
GO
it shows this warning in sql
When the FILESTREAM database option NON_TRANSACTED_ACCESS is set to FULL and the READ_COMMITTED_SNAPSHOT or the ALLOW_SNAPSHOT_ISOLATION options are on, T-SQL and transactional read access to FILESTREAM data in the context of a FILETABLE is blocked.
Now I continue and create the table, and insert folder and file not problem.
My problem to read data, when read data is show this error:
Msg 33447, Level 16, State 1, Line 2
Cannot access file_stream column in FileTable 'File', because FileTable doesn't support row versioning. Either set transaction level to something other than READ COMMITTED SNAPSHOT or SNAPSHOT, or use READCOMMITTEDLOCK table hint.
I'm using EF code first - how to resolve this problem?
You must run this command to have the ability to SELECT the table.
USE [master]
GO
ALTER DATABASE [dbname] SET READ_COMMITTED_SNAPSHOT OFF WITH NO_WAIT
I'm using VFPOLEDB to connect to an VFP database (directory of dbf files).
Once connected, I manually create a table using:
create dbf critera(field_name c(30))
At this point, I verify a new dbf file is created in the database directory. I then try to query the new table, it should return no rows.
select * from criteria
I am presented with the following error:
File "criteria.dbf" does not exit.
Strange, eh?
So I manually delete the DBF file (VFPOLEDB doesn't support drop) and then run the following query.
create db criteria(field_name c(30)); select * from criteria
And get no error, no results returned as expected.
What gives? Any suggestions?
First, (could be a type-o), you had
create dbf Critera (missing the "i")
and then
select * from Criteria (has the "i")
If not that... for your connection string, are you just connecting to the PATH that the .dbf files will be located, or are you explicitly connecting to a path and database.
If just a path
string YourVFPConnectionString =
"Provider=VFPOLEDB.1;Data Source=c:\\SomePath\\WhereDataIs\\";
Or with a specific database container
string YourVFPConnectionString =
"Provider=VFPOLEDB.1;Data Source=c:\\SomePath\\WhereDataIs\\YourDatabase.dbc";
It might be easier to test just by pointing to the directory. The VFP OleDB provider will consider the path the root for any tables queried vs a full .dbc (database container) which could give you access to other stored procedures and such.
The OleDb doesn't support "DROP TABLE". You can still delete a file by running an ERASE "Criteria.dbf" via the OleDbCommand's ExecuteNonQuery()
As for the last one, VFP doesn't utilize the ";" as a break between statements like other SQL engines do where you could send a series of queries all together one after another. ";" in VFP is considered a "this command continues on the next line", and should have thrown an exception is it wouldn't have been able to process it.
Our Application is an MVC Application. We are using Entity Framework. When I am updating the model to add a table from the database. I am recieving an exception and it says
"An exception of type 'System.ArgumentException' occured while attempting to update from the database. The exception message is: 'An entry with the same key already exists'."
I am not able to figure out what is the problem. Can I have a solution to get over the problem.
I had it just as you did. You probably have two identical nodes: EntitySetMapping. You should remove one and everything will be ok.
I ran into this issue today. It means that you have two definitions of some sort with the same name. In my case, it was a duplicate EntitySetMapping. It happened as a result of me migrating some customizations from an old version of my model into a new version. I copied an EntitySetMapping with custom insert/delete/update mappings, but I didn't think to delete the mapping that had been previously auto-generated by the model designer.
Unfortunately, you won't know you have this problem until the next time you attempt to update from the database, meaning there's potential for this one to go undetected for some time.
In the future, when making significant changes to the model via the XML editor, I would recommend that you do a test database update just to make sure that all is well.
I recently ran into a similar issue with EF6 where this error was occurring and there was no duplicate key anywhere... That were visible in the edmx. What I had to do was right-click in the edmx and select Model Browser. In the Model Browser view and under Model/Entity Types, some lingering entities were there. For some reason, deleting all the entities in the edmx actually didn't do what you would think. Removing these lingering Entities in the Model Browser solved my problem. Hopefully this will solve some people's problems because this type of solution is easy to fix but hard to find.
Probably, there is another table with the same key exists. Can we see the code? Read more on this exception here.
Well, it seems I figured out a fix for my case.
Step 1: I deleted the table from the edmx model that contained the reference or what ever that was causing the error.
Step 2: I right clicked the designer and click "Update Model from Database" again and all was fixed.
FYI, the only way I knew which table to delete was because it was the last one modified since the "Update Model from Database" worked last.
Taken From Here
This is a more detailed answer based on Tazos333's answer.
Finding the actual duplicate is the hardest part. Using Powershell it can be done by:
Get-Content .\models.edmx | Group-Object | Where-Object { $_.Count -gt 1 } | Select -ExpandProperty Name
In order to get as few false positive results as possible, run this only for the <!-- C-S mapping content --> section (copy-pasted in other text file).
Besides scalar properties duplicates (quite normal, since tables might contain the same column names), the duplicate <EntitySetMapping Name="..."> will be very obvious.