SQL Server to DB2 Conversion: Migration Toolkit Issues - sql-server

I am trying to convert from MS SQL Server 2008 Express to DB2 9.7.
I have installed IBM Migration Toolkit and successfully connected to my SQL Server database (hosted locally).
I tried to extract from database, keeping all default data mappings, but when I extract, I get the following (for all the tables) - Has anyone had a problem like this where all column types are null with Migration Toolkit?
At first I thought it might be because I am using the Express edition of SQL Server and maybe it couldn't see the column types under this application, but the fact that Name and Unit are null(50) and therefore it has understood that these columns have associated lengths makes me doubt this.
CREATE TABLE [Action] ([Id] null IDENTITY , [Name] null(50) NOT NULL , [UserId] null NOT NULL , [FreqId] null NOT NULL , [Quant] null NULL , [Unit] null(50) NULL , [Start] null NOT NULL , [End] null NOT NULL , [Created] null NOT NULL , [Modified] null NOT NULL , [Deleted] null NOT NULL )

I'm currently use DCW(data conversation workbench) toolkit, it's very useful to get all the data table of SQL Server 2008.
You may try DCW. Remind to you: after installing plugin to DB2, you must add driver of sql to DB2 (window->reference->data management -> connectivity> drive definitions)

Related

Does Microsoft SQL Server provides bitemporal historization?

I want to use bitemporal historization in Microsoft SQL Server as in know it from e.g. DB2 (https://www.ibm.com/docs/en/db2-for-zos/12?topic=tables-creating-bitemporal).
There we can create a table via
CREATE TABLE policy_info
(policy_id CHAR(4) NOT NULL,
coverage INT NOT NULL,
bus_start DATE NOT NULL,
bus_end DATE NOT NULL,
sys_start TIMESTAMP(12) NOT NULL GENERATED ALWAYS AS ROW BEGIN,
sys_end TIMESTAMP(12) NOT NULL GENERATED ALWAYS AS ROW END,
create_id TIMESTAMP(12) GENERATED ALWAYS AS TRANSACTION START ID,
PERIOD BUSINESS_TIME(bus_start, bus_end),
PERIOD SYSTEM_TIME(sys_start, sys_end));
where
SYSTEM_TIME (works in MSQL_Server) refers to technical information in database changes and logs everything in a history-table and
BUSINESS_TIME (does it exist in MSQL server?) refers to the business-reated validity of data (e.g. the lastname of Employee with Employee_ID = 4711 was "Schmidt" from 3.6.21 until 5.7.21 and "Müller" from 6.7.21 until 23.1.22).
Does Microsoft SQL-Server provide a feature analogue to the BUSINESS_TIME in DB2?
Answer from comment: There is no bitemporal historization for SQL-Server.

Error “The timezone provided to builtin function todatetimeoffset is invalid.”

In SQL Server 2008 R2 the function TODATETIMEOFFSET shows the following error:
The timezone provided to builtin function todatetimeoffset is invalid.
In some installations of SQL Server 2008 R2 the function works (same database and same code)
This is the code I’m using, it is part of a stored procedure:
-- table to contain every office timezone offset in minutes
DECLARE #mOfficeOffsetsT TABLE
(
[OfficeCode] VARCHAR(20) COLLATE SQL_Latin1_General_CP1_CI_AS primary key,
[OffsetMinutes] INT
);
INSERT INTO #mOfficeOffsetsT ([OfficeCode], [OffsetMinutes])
SELECT
[OfficeCode], [OffsetMinutes]
FROM
[dbo].[GetOfficeOffsets](); -- GetOfficeOffsets function get all offices offsets in minutes, for example: -180
DECLARE #mNow DATETIMEOFFSET;
SET #mNow = SYSDATETIMEOFFSET();
SELECT
NTF.[NotificationId],
NTF.[ScheduleDate],
NTF.[AppointmentId]
FROM
[Notification] NTF
INNER JOIN
[Appointment] AP ON NTF.[AppointmentId] = AP.[AppointmentId]
INNER JOIN
#mOfficeOffsetsT OO ON AP.[OfficeCode] = OO.[OfficeCode]
WHERE
TODATETIMEOFFSET(AP.[AppointmentDate], OO.[OffsetMinutes]) <= #mNow;
Notification table columns:
[NotificationId] [int] IDENTITY (1, 1) NOT NULL,
[ScheduleDate] [datetime] NOT NULL,
[AppointmentId] [int] NOT NULL,
.. other columns ..
Appointment table columns:
[AppointmentId] [int] IDENTITY (1, 1) NOT NULL ,
[OfficeCode] [varchar] (20) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL ,
[AppointmentDate] [datetime] NOT NULL ,
.. other columns ..
My function “GetOfficeOffsets” doesn’t seem to be the problem, because if I hardcode #mOfficeOffsetsT table rows the error remains.
The data in the tables seem to be ok.
I have reproduced the error in:
SQL Server 2008 R2 RTM
SQL Server 2008 R2 SP1
SQL Server 2008 R2 SP2
SQL Server 2008 R2 SP3
SQL Server and database collation I'm using: SQL_Latin1_General_CP1_CI_AS
The OS does not seem to have influence:
Windows Server 2008 R2 Enterprise (production) >> get the error
Windows Server 2008 R2 Standard (testing) >> works well
Windows Server 2008 R2 Enterprise (dev) >> works well
Windows Server 2008 R2 Datacenter (dev) >> get the error
OS Region and Language settings does not seem to have influence.
Does anyone know what may be causing this strange error?

Sql Server ODBC Date Field - Optional feature not implemented

I have a SQL Server table which has fields of type Date in it. I am trying to update or insert a record into the table via Micosoft Access using ODBC. I get the error:
[ODBC SQL Server Driver]Optional feature not implemented
when I try and update or insert a record.
I have to use Date fields not DateTime fields in my table because I am using very old dates going back 2000 years.
Is there any way round this problem, which I assume is caused by the Date fields?
This is what the table looks like
CREATE TABLE [dbo].[Person](
[PersonId] [int] IDENTITY(1,1) NOT NULL,
[DOB] [date] NOT NULL,
[DOD] [date] NULL DEFAULT (NULL),
[Name] [nvarchar](100) NOT NULL)
You best bet is to dump the use of the "legacy" sql driver, and user the newer native 10 or 11 driver. The older driver will view date fields as text, but using the newer native 10/11 driver will see the column as a date column. This will require you to re-link your tables.
If you can't change your SQL Server version, an easier solution is to pass the date as an adVarChar, and then do a CAST(#param AS DATE) in your SQL stored procedure.
I've experienced the same problem today.
I use MsAccess 2010 for developlemt, and have MsSql2012 at back-end.
There was no problem on my computer,
but other clients that use the accde runtime version has experienced this trouble.
After several trials;
Issue resolved when replacing DATE type with SMALLDATETIME. please try this..?
Indeed I only needed the date part, not the time, but ok anyway!
[DOB] [date] NOT NULL,
[DOD] [date] NULL DEFAULT (NULL),
Hope this helps to you as well

Unknow database [...] when selecting the database (Ubuntu)

I'm trying to work with MySQL on my laptop (Ubuntu) and always that I have to export a .sql file to database, the console show me the same message: "unknow database Spotify (for example) when selecting the database".
The sql script is correct, and must work, but always show the same message; any solution?
CREATE DATABASE Spotify;
USE Spotify ;
DROP TABLE IF EXISTS Spotify.Usuarios ;
CREATE TABLE IF NOT EXISTS Spotify.Usuarios
(
iduser INT NULL ,
user VARCHAR(10) NULL ,
password VARCHAR(45) NULL ,
reg VARCHAR(45) NULL
) ENGINE = InnoDB;
Finally, I solved it: there was a problem with Ubuntu packages, and the mysql's installation didn't finished correctly

How to script non-default collation and skip explicit scripting for default collation?

In SSMS 2008 R2, I created a table:
aTest(Albnian varchar(10), Dflt varchar(10))
In SSMS table designer, both columns have the collation: "<database default>" (under "Column Properties" → "Table Designer")
I changed the collation of the column "Albnian" to a non-default, for example, Albanian_CI_AS.
If I script the table in SSMS (right click on "aTest" → "Script Tables as" → "CREATE To" → "New Query Editor Window", I get [1] with no explicit collations scripted at all.
Bad.
Obviously, one would expect the table to be scripted with explicit collation for non-default collation (the one that the developer intentionally introduced with a specific purpose) and no collation for default collation.
In SSMS menu → Tools → Options → SQL Server Object Explorer → Scripting, I changed:
Include collation: True
Script defaults: False
but now, I am getting all column collations scripted, both default and non-default ones [2].
How can I configure script generation to script non-default collation and skip the default ones, as in [3]?
[1] Default scripting of table:
CREATE TABLE [dbo].[aTest]
(
[Albnian] [varchar](10) NOT NULL,
[Dflt] [varchar](10) NOT NULL
) ON [PRIMARY]
[2] Table script after "Include collation" changed to True
CREATE TABLE [dbo].[aTest]
(
[Albnian] [varchar](10) COLLATE Albanian_CI_AS NOT NULL,
[Dflt] [varchar](10) COLLATE Cyrillic_General_CI_AS NOT NULL
) ON [PRIMARY]
[3] Needed collation script generation behavior:
CREATE TABLE [dbo].[aTest]
(
[Albnian] [varchar](10) COLLATE Albanian_CI_AS NOT NULL,
--non-default should be scripted
[Dflt] [varchar](10) NOT NULL
-- default database collation should not be scripted
) ON [PRIMARY]
Related question:
What issues to anticipate having different collations between development and production SQL Servers?
I submitted a suggestion through MS Connect:
Collations are scripted either for all columns or for none
Here's the related response:
Posted by Microsoft on 11/11/2010 at 10:16 AM
Hi Gennady:
Thanks for writing in to Microsoft. We greatly value your feedback. We understand your problem, and how fixing this could improve productivity.
However, given the work that would be involved in implementing this work, and our set of deliverables, we do not think, we would be able to get to this in the near future.
Having said that, we value your suggestions, and would like to assure you that, we would keep these ideas in mind, when we do revisit this feature in the future.
Thanks again for providing feedback and making SQL Server the greatest Database server.
Regards
Chandramouli

Resources