Devart Forums

When using backuptofile with mySQL there can be added drop and create statements for each table. When using MS SQL server as provider this does not seem to be possible, or am I missing something !?
Is there another solution to get the create table info into my backup file when using MS SQL !?

Unfortunately, for the time being TUniDump doesn't have the functionality you need for SQL Server. We have plans to improve the TUniDump component in the future and we will take into account all suggestions from our users about it. You can leave your suggestion at our UserVoice page at http://devart.uservoice.com/forums/1046 ... components . Suggestions with many votes will be implemented faster.

ok.

I hope to see that function in the future.

Until that ... I created my own function/script that handles the data types that I am using in my tables. And run this script before the restorefromfile.

Problem with restoring #10 and #13.
Database : MS SQL server 2008 R2.
Unidac : 4.6.12

Table def
CREATE TABLE [dbo].[matprn_asciitabel](
[Name] [varchar](20) NOT NULL,
[ID] [int] NOT NULL,
[Value] [varchar](1) NULL,
PRIMARY KEY CLUSTERED
(
[Name] ASC,
[ID] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]

Using unidump.backuptofile gives this in the backup file :

INSERT INTO matprn_asciitabel(Name, ID, Value) VALUES ('PRNFIL', 10, 'x')

where x is the char value of #10 (but inserting #10 here gives a line break)

But when I use unidump.restorefromfile I get an error message :

The statement has been terminated.
String or binary data would be truncated.
INSERT INTO matprn_asciitabel(Name, ID, Value) VALUES ('PRNFIL', 10, 'x')

What is wrong !?

The #10 character is a non-printed character and is reserved for the line breaking. If you want to store the #10 character (as well as any other non-printed characters) to the database and use it in the SQL statements (like TUniDump does), you should use the varbinary(1) column instead of varchar(1).