G'day all. We have a very large table in SQL 2005 containing over 200m records and one of the column is a XML data type. We are upgrading that database to SQL 2012 and hence the data need to be transferred across. For large db's (> 500 GB) we have figured out using SSIS is faster when compared to other traditional methods.
The question is, is there a faster way to transfer the table containing xml data type other than mapping the OLEDB Source to OLEDB Destination using SSIS?
Thanks all
Take the backup in SQL server 2005 and restore that backup in sql server 2012 or you can take the help of SQL server 2012 upgrade advisor before migrating the DB to find out the potential conflicts.
Related
We are using informix db on linux operating system.Is there a way we can know history of queries that have been executed through isql ?
The Informix server has a feature for SQL tracing that is enabled with the SQLTRACE onconfig parameter. This can be set to collect various levels of information relating to executed statements including the statement text. This is maintained in an in-memory circular buffer so the information would need to be extracted from this buffer and stored separately if you wanted to maintain a permanent history.
There is more information on this feature in the Informix Adminstrator's Guide at https://www.ibm.com/support/knowledgecenter/SSGU8G_12.1.0/com.ibm.admin.doc/ids_admin_1126.htm
Does the DBMS save the compiled queries from prepared statements in JDBC, in the form of stored procedures on the DBMS server? I thought that prepared statement isn't a concept in DBMS but in JDBC, so I was wondering how it is implemented on DBMS server side.
My question comes from Why do Parameterized queries allow for moving user data out of string to be interpreted?
I read DIfference Between Stored Procedures and Prepared Statements..?, but don't find my answer.
Thanks.
I am interested in PostgreSQL, MySQL, or SQL server in order.
No, prepared statements are not implemented as stored procedures in any RDBMS.
Prepared statements are parsed and saved on the server-side so they can be executed multiple times with different parameter values, but they are not saved in the form of a stored procedure. They are saved in some implementation-dependent manner. For example, as some kind of in-memory object, totally internal to the code of the database server. These are not callable like a stored procedure.
Re your comment:
Consider MySQL for example.
MySQL in the very early days did not support prepared statements, so the MySQL JDBC driver has an option to "emulate" prepared statements. The idea of emulation mode is that the SQL query string is saved in the JDBC client when you create a PreparedStatement. The SQL is not yet sent to the database server. Then when you bind parameters and call execute(), it copies the parameter values into the SQL query and sends the final result.
I don't know whether a similar feature exists in other brands of JDBC driver.
unfortunately i have to work with ancient piece of software, that uses paradox tables.
The following code gives me exception:
fdcMainPX->TxOptions->AutoCommit=false;
fdcMainPX->StartTransaction(); <---
"Project xxx raised exception class EFDException with message '[FireDAC][Phys][ODBC]-303. Capability is not supported'"
It appears, that windows odbc driver for paradox doesn't support transactions. I suppose that ole jet engine allows transactions with paradox but i'd rather use Firedac over ADO or BDE.
How to set up connection with firedac to use MS Ole db ?
Maybe there is another way?
I am using C++ Builder XE6 Pro with Firedac
Paradox DBMS doesn't seem to be capable of transactions at all (maybe its new version, part of the Corel product is, but that doesn't seem to be your case).
However, if you just want to keep consistency of certain data batches in a single connection session, you can use cached updates.
I'm in the process of converting a Paradox database application written in Delphi to use SQL Server 2008 R2. We are using the UNIDAC components from Devart to access the database/tables. However, I am finding the performance rather slow. For example, in the Paradox version it is more or less instant when it opens up a table (Using TTable) with 100,000 records, but the SQL Server (Using TUniTable) take approximately 2 seconds. Now I know this doesn't seem a lot but there are 10 TUniTable datasets which open up on form creation, all of which contain around the same number of records, so at present it is taking just under 20 seconds to open them all. Does anyone have any performance tips?
I'm using Delphi 2007
IMHO, UniDAC TUniTable is just a wrapper of TUniQuery. TUniTable open may lead to fetching all records on SQL Server. Not sure how, but try to change SQL Server cursor type and/or location.
If it is not late, then consider to use AnyDAC and TADTable. It uses "Live Data Window" technology, which allows to open and browse through the large tables without significant delays, eg Open and Last calls will be always fast. We migrated few BDE applications to AnyDAC and Firebird, TADTable works really great.
I'm attempting to fix some problems with some old VB6 code for a client, and the previous programmer used Activex Data Object 2.7 stored procedures. After a recent computer failure and reimage, none of the buttons that use stored procedures in the application currently work.
So, my question is where can these procedures be stored?
Thanks
Stored procedure are on the database. Unless the database was on the local machine, there are only a few things of which I can think that could have been broken/reset by a re-image.
These are all used to remap computer name references.
HOSTS
DSN
SQL Aliases