I am trying to convert and migrate an Oracle schema to MSSQL server. At the last step, migrating data, I get the error message:
The table [MYDATABASE].[MYSCHEMA].MYTABLE] doesnot exist in target. You must first convert the table then load it into the database.
This error message appears for each table in my schema.
Can someone explain what is happening and what I need to do to get past this?
Are you tries to migrate the data before doing the ‘synchronize with the database’ operation?
If Yes,
This error message generally occurs when the target table doesn’t
exist on SQL server database. After converting schema, you need to
synchronize the table with the database before migrating the data.
To do this you right click on the SQL Server database in Metadata
explorer and click “Synchronize with database” menu.
Note: Table structure will not be created in the SQL server database until you synchronize.
Related
I was forwarded a Crystal Reports error message that said:
Failed to retrieve data from the database. ... Description: The EXECUTE permission was denied on the object 'xxxx_IDList', database 'DBName', schema 'dbo'.
There is an 'object?' named 'xxxx.IDList' under User-Defined Table Types - in the database.
I have never created or used a User-defined Table Type so I am just trying to figure out how to approach this error and how I might proceed with troubleshooting it.
I am hoping this is not an uncommon error.
Can anyone suggest an approach to solving this problem?
Thanks in advance!
In SQL server, any table that is not a system table is a user-defined table. So, anything in a typical non-system database that holds business data. The error message tells me that you have a database (dbname) on the server you are connecting to. In that database there is at least one schema (dbo, which is the default) and that the table xxxx_IDList lives in that schema.
Your app is trying to execute this table as if it was a function or stored procedure and you do not have permission to do that.
Do you have the source for the app that we can look at?
The report server was unable to validate the integrity of encrypted data in the database. (rsCannotValidateEncryptedData) .
Could not restore the encryption key, so I deleted the keys and tried to regenerate with rskeymngt with no luck. Getting
'The report server was unable to validate the integrity of encrypted
data in the database. (rsCannotValidateEncryptedData)'
I get that error when accessing http://localhost/ReportServer and when running rskeymgmt -s.
Not sure what next step to take. I have reports that users need to access.
I went into SSRS Configuration Manager > Encryption Keys > click Delete.
When I did that I got the error:
Failed to delete the encryption content in the report server database. Please execute the "DeleteEncryptedContent" stored procedure on the database manually.
To fix it I opened SQL Server Mgmt Studio > expand Databases > right click Report Server > new query and execute:
exec DeleteEncryptedContent
Start > Run > services.msc > Restart the "SQL Server Reporting Service" and its working.
Restarted the services and now everything is working.
So it looks like in order to generate a new key I need to update the Report Server Service account. After that restart the sql server reporting services.
I no longer have the encryption error, but now I am asked for a log in to the data source after clicking on the report. I enter the creds again but get 'The ConnectionString property has not been initialized.'
Just go to the reporting service manager and delete the delete encrypted content or change content now try to connect once more it will be work.
You just need to change database again if you already created then your problem will be solved.
One reason for this could be that the encryption key did not restore correctly. I migrated a report database from one server to another. I restored the encryption key and all seemed well at first but the error the questioner posted started appearing shortly thereafter. Another site had posted a query to look at the keys in the report database (with further instructions of how to delete) and I noticed when I executed it that the SymmetricKey field for my server was NULL. I restored the encryption key again using the Report Server Configuration Manager and noticed that the SymmetricKeys was now populated. I was then able to browse to the report server.
So I have setup T-replication from Publisher (SQL Server 2014) Distributor (SQL Server 2014) Subscriber (SQL Server 2008 R2) and initialized it using a snapshot.
Checking in the replication monitor I find that the Snapshot agent has completed successfully and Log Reader agent is running.
Now in 'Distributor to Subscriber History' tab just beside the 'Undistributed Commands' Tab
I get the following error:
The process could not bulk copy into table '"dbo"."BEAMDATA"'. (Source: MSSQL_REPL, Error number: MSSQL_REPL20037)
Get help: http://help/MSSQL_REPL20037
End of file reached, terminator missing or field data incomplete
To obtain an error file with details on the errors encountered when initializing the subscribing table, execute the bcp command that appears below. Consult the BOL for more information on the bcp utility and its supported options. (Source: MSSQLServer, Error number: 20253)
Get help: http://help/20253
bcp "LOWIS_BUCT"."dbo"."BEAMDATA" in "C:\Program Files\Microsoft SQL Server\MSSQL12.MSSQLSERVER\MSSQL\ReplData\unc\LOWISBUCT_CSSQLDB_BUCT_CSSQLDB_BUCT_ALL_TABLES\20160826064516\BEAMDATA_34#1.bcp" -e "errorfile" -t"\n\n" -r"\n<,#g>\n" -m10000 -SLOWISTSTSQL -T -w (Source: MSSQLServer, Error number: 20253)
Get help: http://help/20253
I thought this could be some kind of data overflow and hence checked the schema of the table at both Publisher and Distributor and they match exactly.
I cleaned the whole replication setup completely and re did it but still stuck at the very same place for the same table.
Has anyone encountered this before? Ask me if you need more information from my end which I can furnish.
I found the reason for this. It was due to the schema mismatch at the publisher and subscriber.
In the said table, column had the datatype (date(datetime) and when replication scripted the schema for this table it was scripted as date hence at subscriber when the snapshot was applied, the field had the data type of date.
When data was being copied from datetime to date field it resulted in the said error.
I did the necessary changes in the data type at the subscriber end and things got fixed,
I had a similar error and Problem "sql replication repl20037 field size too large". What i found is this. I setup the subscription with my local Sql Management Studio v18.10 on a SQL Server 12.0. This caused the the Bulk copy problem and a field mismatch. Solution: setting up the Publication directly on the Mgmt Studio on the source server and setting up the subscription directly on the Mgmt Studio on the destination server.
From the Object Explorer of SQL Server Management Studio I renamed a table from nameA to nameB. When I query SELECT * from nameB I receive the error
object name 'nameA' not valid
This happens both from Management Studio and an external application. SELECT * from nameA gives the same error.
Restarting the service didn't help. Table name in sysobjects is correct. Is there maybe another place where SQL Server looks up table names? Thanks, it's getting me quite crazy :S
I'm using SQL Server 11.0.2100.60
Solved with a workaround:
I generated scripts for table schema and data, dropped the table and run scripts to recreate table schema and data. NOTE: I needed to manually modify the generated scripts because of mistakes in smalldatetime fields which made the generated INSERTs fail.
So it seems that dropping tables resets the "denormalized" SQL Server internal catalog which was left inconsistent somewhen. Thanks MS! ;)
I have been trying for the past week or so to import data programmatically to a SQL Server 2008 table from a Microsoft Access .mdb file. I have been getting nothing but errors, and solving one just reveals another. I made the file into a linked server, and now when I try to query it with:
Select * from OPENQUERY(Importdata, 'Select * from [IMBPieceBC]')
I get the error:
OLE DB provider "Microsoft.Jet.OLEDB.4.0" for linked server "Importdata" returned message "Cannot open database ''. It may not be a database that your application recognizes, or the file may be corrupt.".
Msg 7303, Level 16, State 1, Line 1
Cannot initialize the data source object of OLE DB provider "Microsoft.Jet.OLEDB.4.0" for linked server "Importdata".
I've read several suggestions to relink dlls in the registry, but I've done that, and I'm still getting the error. Is there anything else I can do to fix it, or at least figure out what is wrong?
Migrating the data to a SQL Server instance is not an option. The mdb files are generated by a third-party program, so there's nothing we can do about it.
I have a similar situation at my workplace - a third party application that maintains data in MDBs, but other applications needing access to it. How I've done it is that this 'intermediary' application has links to the SQL Server tables and the MDB tables. You could use either a query or a VBA written form event to transfer information from the MDB table(s) involved into your corresponding SQL Server tables using a INSERT INTO query, fitted with a SELECT FROM subquery providing the values being inserted.