I have about 1200 databases in SQL 2016 Enterprise in which documents are stored as BLOB's in image fields in the database. I migrated all the documents to our Document Management System and now I want to replace the files in the database with shortcuts to the corresponding files in the DMS. I tried it a few months ago and that went well. Now I run into an issue. When I use this command
convert(varbinary(max), <string value of shortcut>)
It get's written to the field. When I try to open the shortcut I get an error. If I create the same shortcut from our DMS it is exactly the same except for the encoding. My binary = UTF-16 little endian and the DMS shortcut is encoded in UTF-8. The filesize has also doubled, which is logical since UTF-16 uses two bytes for every character. When I change the encoding in Notepad++ my shortcut works.
I need my blob to be encoded in UTF-8. That is possible, I can upload a shortcut to the system that the database uses and then it's stored correctly. I can't change the collation of the table or field because this is a vendor database. It's a pretty old-fashioned system. Who uses Blob's in the first place and if you do, why image and not varbinary?
I'm not much of a programmer so any help would be greatly appreciated.
I tried updating the database to the latest client version (not SQL just the application). That didn't change anything.
I tried nvarchar but that doesn't work on image fields.
Related
I am using both Oracle Forms version 11g and 12c.
Is it possible to find a table for e.g table1 used in the Oracle Forms application screens including LOV's without opening each FMB individually and searching in it.
Totally there are around 50-75 FMBs in the application.
Thanks
While Forms was a new software product, back then in its 3.0 version (or even lower), you could choose whether you'll keep the form source
in the database or
in that case, you could have written a query which selects data from the data dictionary and - hopefully - extract tables' names
in file system
file extension was .INP (not .FMB) and it was a textual file; it means that you could even create a form using text editor! Nobody probably did that, but hey - you could have done it.
.FMB is no longer textual file. Yes, you can open it it a text editor (such as Notepad++) and search for e.g. FROM (because any table used in form's PL/SQL units or LoVs is part of a SELECT statement which requires the FROM keyword) and get something like this:
Yes, you'll get "duplicates" if any table is referenced more than once.
Another option is to write a program which will parse the .FMB file and extract tables' names (I can't help with that, though).
I am trying to load data from file into Relational target. Target DB is Oracle.
In source file we have data for one account is having special characters.
eg: Viswanathan^A# de
In our application we have length of this field is 50. So we have in Informatica also 50.
Other data are loaded properly without any issues. Those data doesn't have special characters.
Finally while loading the data, it is truncated like Viswanathan d. So the char e is not loaded. Because of that the application has rejected this record.
I would like to know how to see and set the code page is available for Target and source.
i think the issue is with data length or may be code page. Probably you are trying to insert unicode data (data with ascent - Dé). You can change below settings and try again.
you can change the code page of target like below screenshot. You can make it like unicode.
Change integration service mode to Unicode.
Make the length of the target column to varchar2(100 char). To store Unicode values you need double the size than ascii values.
I am a greenhorn in Oracle Database and IBM Integration Bus and I'm trying to use the INSERT INTO function of ESQL in the IBM Integration Bus to insert data of a CSV file.
I'm using a DFDL with ISO-8859-1 encoding to read the file. When using the debugger, the message is fine and readable in SQLPLUS and SQL Developer.
I already tried to change the NLS_CHARARCTERSET setting in my Oracle Database although im not really sure which encoding I need. On default it was AL32UTF8 and I tried UTF8, WE8ISO8859P1.
What I also did was changing the encoding of the DFDL and changing the ODBC driver's settings to Use Oracle NLS Settings (Default), Use Microsoft Regional Settings and Use US settings.
If I try to use the INSERT INTO command the Database returns inverted question marks or Chinese characters, which is obviously not what I want.
EDIT:
If I hardcode the INSERT INTO values it also returns the question mark. The CSV's encoding doesn't matter. What I also found out is that the CSV file's data is displayed as null. When I hardcode the values in the INSERT INTO I get inverted question marks.
Its a simple option in the IIB ODBC Driver for Oracle. Just make sure that "Enable SQL Describe Param" in the advanced tab is checked.
If you mean the encoding of the CSV file. It is Windows 1250 since the input file has characters like 'ß'
I don't understand that statement. The use of the character 'ß' does not necessarily imply Windows 1250. Do you have any other supporting evidence for that claim?
If your claim is correct then your DFDL schema is incorrect. You cannot parse a multi-byte encoding using a single-byte decoder. So the first thing you should do is to change the 'encoding' property in the format block of your DFDL schema to "5346" (according to https://www.ibm.com/support/knowledgecenter/en/SSRH46_3.0.0_SWS/dni_ccsids_and_char_set_names.html ).
But (and I'm sorry for repeating this, but it really matters...) CHECK that your assumption about Windows 1250 is correct. Then make sure that the encoding in the DFDL schema matches the encoding of the CSV file.
We have a portal written in php/mysql and an enterprise application based on Java EE and Oracle. Recently we found out that a certain Unicode character (0643 to be precise) is invalid (due to improper data entry by end users) in text columns and must be changed to another character (06A9).
In MySQL I simply changed the export file using a text editor's find and replace tool. But in oracle, the dmp file is a binary file and i have no idea about how to edit the dmp file.
How can I change the invalid character?
Is there an alternative to iterating through all text columns in all tables?
(I have saved that as a last resort!)
Editing an Oracle dump file may be possible but isn't practical; even if you could get in and change something you'd risk corrupting it, and I doubt Oracle support would be impressed. (See this AskTom question for example).
If you're using data pump and you know which column(s) the data is in you might be able to use the REMAP_DATA parameter to change it on the fly, or the QUERY parameter to skip the data, but it doesn't sound like you're in that situation. You could potentially add temporary constraints to the relevant column(s) to block the value, so import would reject (and log) the affected rows, but that's painful and messy.
If you do have to check all columns on all tables, this link may be helpful.
I was reading on internet these statements about SQL Server data types:
VARBINARY(MAX) - Binary strings
with a variable length can store up
to 2^31-1 bytes.
IMAGE - Binary strings with a
variable length up to 2^31-1
(2,147,483,647) bytes.
Is there a really big technical difference between VARBINARY(MAX) and IMAGE data types?
If there is a difference: do we have to customize how ADO.NET inserts and updates image data field in SQL Server?
They store the same data: this is as far as it goes.
"image" is deprecated and has a limited set of features and operations that work with it. varbinary(max) can be operated on like shorter varbinary (ditto for text and varchar(max)).
Do not use image for any new project: just search here for the issues folk have with image and text datatypes because of the limited functionality.
Examples from SO: One, Two
I think that technically they are similar, but it is important to notice the following from the documentation:
ntext, text, and image data types will be removed in a future version of MicrosoftSQL Server. Avoid using these data types in new development work, and plan to modify applications that currently use them. Use nvarchar(max), varchar(max), and varbinary(max) instead.
Fixed and variable-length data types for storing large non-Unicode and Unicode character and >binary data. Unicode data uses the UNICODE UCS-2 character set.
They store the same data: this is as far as it goes.
"image" is deprecated and has a limited set of features and operations
that work with it. varbinary(max) can be operated on like shorter
varbinary (ditto for text and varchar(max)).
Do not use image for any new project: just search here for the issues
folk have with image and text datatypes because of the limited
functionality.
In fact, VARBINARY can store any data that can be converted into a byte array, such as files, and this is the same process that IMAGE data type uses, so, by this point of view, both data types can store the same data.
But VARBINARY have a size property, while IMAGE accepts any size up to the data type limits, so when using IMAGE data type, you will spend more resources to store the same data.
In a Microsoft® SQL Server®, the IMAGE data type is really deprecated, then you must bet in VARBINARY data type.
But be carefull: The Microsoft® SQL Server® CE® (including the latest 4.0 version) still using IMAGE data type and probably this data type will not "disappears" so soon, because in Compact Edition versions, this data type is better than any other to fast files storage.
I inadvertently found one difference between them. You can insert a string into an image type but not into a varbinary. Maybe that's why MS is deprecating the image type as it really doesn't make sense to set an image with a string.