BETA
Aby się zalogować, najpiew wybierz portal.
Aby się zarejestrować, najpiew wybierz portal.
Podaj słowa kluczowe
Słowa kluczowe muszą mieć co najmniej 3 sąsiadujące znaki alfanumeryczne
Pole zawiera niedozwolone znaki
Łukasz Herman Ekspert WSS
Łukasz Herman
3540 pkt.
Guru

 
0


 
Od jakiegoś czasu męczy mnie jeden problem i nie wiem jak najbardziej elegancko go rozwiązać.
Potrzebuję zrobić import danych z jednej bazy do drugiej. W zasadzie to tylko potrzebuje przenieść jedną tabelę z bazy DBF (Visual FoxPro) do MSSQL.
 
Pomijając już kwestię providera i kodowania w Visual FoxPro, pierwsze co przychodzi na myśl to stworzenie paczki SSIS.
Problem jest w tym, że tą operację muszę wykonać z poziomu aplikacji ASP.NET (w zasadzie to WebService), na publicznym hostingu. A więc nie mam za wiele opcji jak się dobrać do serwera, a już tym bardziej utworzyć joba.
 
Rozwiązanie I
Stworzyłem klasę, która wykonuje paczkę SSIS.
Działa fajnie pod warunkiem, że na maszynie na której działa aplikacja jest zainstalowany komponent SQL Server Integration Services. Inaczej nie ma dostępu do klas i wszystko się wywala.
Niestety samo wrzucenie klasy Microsoft.SQLServer.ManagedDTS nie wystarczy, bo i tak ona odwołuje się do czegoś tam jeszcze i zwraca mało mówiący błąd:




Server was unable to process request. ---> An Integration Services class cannot be found. Make sure that Integration Services is correctly installed on the computer that is running the application. Also, make sure that the 64-bit version of Integration Services is installed if you are running a 64-bit application. ---> Retrieving the COM class factory for component with CLSID {BA785E28-3D7B-47AE-A4F9-4784F61B598A} failed due to the following error: 80040154.




Ktoś może już walczył z tym i doszedł jak to obejść? Ja rozkładam już ręce.
 
Rozwiązanie II
Zrobić zwykłego Select na bazie źródłowej, trzymać dane w pamięci, a następnie dla każdego wiersza zrobić inserta w bazie docelowej. Metoda chałupnicza, ale chyba nie będzie przysparzała tyle problemów.
Kwestia co z wydajnością (wszystko leci przez aplikację ASP.NET) i niezawodnością?
 
Rozwiązanie III
Odpalać paczkę SSIS lokalnie importując dane na serwer zewnętrzny. Zadziała, tylko niszczy całą koncepcję automatyzacji...
 
Rozwiązanie IV
Linked server, albo za pomocą sp_execute, ale nie mam tak wysokich praw na bazie danych z której korzystam.
 
PS. W kwestii paczek SSIS. Zrobiłem paczkę która wyciąga mi odpowiednie dane z tabeli źródłowej. Zmieniam kodowanie z CP620 (Mazovia) na CP1250. Z OleDB Source wychodzą mi wtedy ładne dane z polskimi znakami (podglądam je sobie w Data Flow), ale jak już wpadną do MSSQL to kodowanie się rozjeżdża i polskie znaczki mówią bye bye...
Wszędzie mam ustawione kodowanie CP1250, tak jakby SQL mimo wszystko nie tolerował kodowanie wychodzącego z połączenia OleDB Visual FoxPro.
 
Z góry dzięki za pomoc i dobrnięcie do końca postu ;-)
 
--
Edytowano 1 raz. Ostatnio 2010-11-22 04:01:25 przez hermanluk.
tagi: ASP.NET   SQL   SQL Server



Liczba postów:

PaSkol Ekspert WSS
PaSkol
628 pkt.
Senior
 
0


Czy chodzi o to, aby dowolny komputer za pomocą WebService automatycznie przekazywał plik DBF do bazy MSSQL? Czyli inicjatorem tego działania jest tenże komputer?
 
Czy zatem nie można najpierw przekazać pliku na serwer, który realizuje usługę WebService i po umieszczeniu tamże, usługa go sobie odczyta (spod .NET to trywialne, chociażby tak, jak próbowałeś w osobnym wątku), przerobi na XML-a i w tej postaci poda do MSSQL. Ten sobie XML-a rozparsuje i po sprawie (taki pseudo-bulk).
 
Skoro administratorskie dyby nie pozwalają na zbyt wiele ruchów, to chyba byłoby najlepsze rozwiązanie.
 
No i jeśli to Ty jesteś odpowiedzialny za automat na wspomnianym komputerze wysyłającym, to możesz od razu na nim przerobić DBF na XML. Jeśli ta tabela ARTYKULY.DBF nie ma pliku indeksującego (czyli ARTYKULY.IDX, ARTYKULY.CDX, ARTYKULY.MDX), to praktycznie możesz użyć do jej otwarcia zwykłego Microsoft.Jet.OLEDB.4.0 jako Provider, a ciąg byłby np. taki:
Data Source=D:\BAZA_DBF\;Extended Properties=dBase IV;
 --PaSkol
Rozwiązałem Twój problem? Kliknij poniżej [Rozwiązanie].Jedynie Ci pomogłem? Kliknij [Pomógł mi].

Łukasz Herman Ekspert WSS
Łukasz Herman
3540 pkt.
Guru
 
0


Dzięki za odpowiedź.
 
Po pierwsze sterownik Microsoft.Jet.OLEDB.4.0 nie zadziała z moimi plikami bo korzystam z bazy Visual FoxPro a nie dBase X (ale to już nie problem bo MS jeszcze wspiera odpowiedniego providera).
 
Teoretycznie mógłbym zrezygnować z importu i robić zapytania z pliku poprzez providera, ale chcę rozszerzyć tabele o kolejne informacje. Dlatego tworzę sobie tabelę z dodatkowymi kolumnami.
Jakbym chciał brać dane z dwóch źródeł, to nie jestem w stanie zrobić bardziej konkretnych zapytań do bazy (jak chociażby join).
Indeksy mnie w ogóle nie interesują (gdyby istniały).
 
Docelowo użytkownik ma mieć możliwość uploadowania pliku na serwer, żebym dalej mógł go przetwarzać. I tu najlepiej byłoby odpalić paczkę SSIS, z poziomu .NET łatwo ją można oprogramować.
Tylko niewiele zdziałam bez instalacji Integration Service, a nie udało mi się znaleźć jakie dodatkowe biblioteki musiałbym podłączyć do projektu, żeby uruchamianie paczek działało.
 
Co do XMLa, to nie za duży narzut danych wygenerują tagi?
W tej chwili przesyłam niewielką tabelkę, która ma ledwo koło 1k wierszy i parę kolumn, ale jak to się opakuje w XMLa to może strasznie urosnąć.
 
Ale jest to jakieś rozwiązanie i chyba nawet łatwe w oprogramowaniu. Musze to rozważyć.--

PaSkol Ekspert WSS
PaSkol
628 pkt.
Senior
 
0


sterownik Microsoft.Jet.OLEDB.4.0 nie zadziała z moimi plikami bo korzystam z bazy Visual FoxPro a nie dBase X
 
To zależy, choć jeśli to VFoxPro, to już nie jest tak łatwo. Chodziło mi o to, że Jet-a masz z dobytkiem inwentarza czyli razem z systemem, a sterownik do Fox-a musisz dodatowo doinstalować.
 
Teoretycznie mógłbym zrezygnować z importu i robić zapytania z pliku poprzez providera, ale chcę rozszerzyć tabele o kolejne informacje. Dlatego tworzę sobie tabelę z dodatkowymi kolumnami.
 
Nie rozumiem. Czyli tę tabelę (plik DBF?) tworzysz Ty sam? Jeśli tak, to przecież możesz ją stworzyć w dowolnym formacie. No chyba, że jest tak, jak zrozumiałem, że ten plik DBF to tabela jakiegoś programu napisanego w FOX-ie i po prostu jest przesyłana w całości.
 
Jakbym chciał brać dane z dwóch źródeł, to nie jestem w stanie zrobić bardziej konkretnych zapytań do bazy (jak chociażby join).
 
Też nie zrozumiałem. Wydawało mi się, że po prostu przepompowujesz dane z FOX do MSSQL-a i resztę operacji wykonujesz w MSSQL. Ergo: przy większej ilości tabel FOX/DBF musisz je wszystkie odwzorować w MSSQL.
 
Indeksy mnie w ogóle nie interesują (gdyby istniały).
 
O indeksach pisałem w sensie przeszkody używania ich przez Jet-a, po prostu nie potrafi otwierać DBF w trybie dBase, gdy ten ma indeks.
 
Co do XMLa, to nie za duży narzut danych wygenerują tagi
 
Ja to załatwiam w ten sposób (reprezentacja wiersza z DBF):
 
<r c1="wartość z 1 kolumny" c2="wartość z 2 kolumny" ... cN="wartość z N kolumny"/>
 
Można pomijać puste kolumny (czyli te null + puste tekstowe, ale to drugie już zależy)
Jeśli jest obawa o nieprawidłowe mapowanie c1, .., cN na właściwe kolumny do XML-a można dołączyć sekcję te mapowanie definiującą czyli:
 
<r c1="Identyfikator" c2="Symbol" ... cN="Opis"/>
 
Wypadałoby jeszcze zasugerować użycie płaskiego pliku tekstowego (rozdzielany tabulacją - rozmiar nie wzrośnie w stosunku do DBF znacząco, czasmi może nawet zmaleć) i skorzystanie z bulk insert, ale nie wiem czy administratorskie dyby również tutaj nie okażą się przeszkodą.--PaSkol
Rozwiązałem Twój problem? Kliknij poniżej [Rozwiązanie].Jedynie Ci pomogłem? Kliknij [Pomógł mi].

Paweł Potasiński Microsoft
Paweł Potasiński
7713 pkt.
Guru
 
0


1. Spróbuj, czy nie zadziała metoda ad-hoc distibuted query - użyj OPENROWSET (provider do Office'a). Jakby się okazało, że serwer odpowiada komunikatem błędu (domyślnie ad-hoc distr. queries są wyłączone), poproś administratorów o włączenie (tudzież o możliwość założenia linked servera).
2. Konwersja Mazovia - CP1250 w kilku odsłonach:
http://sqlgeek.pl/2010/06/16/sql-server-jak-wylistowac-dostepne-kodowania-funkcja-tabelaryczna-clr/
http://sqlgeek.pl/2010/06/22/sql-server-konwersja-kodowania-cp620-mazovia-na-cp1250-w-clr/.
 
--
Pozdrawiam,Paweł Potasiński, SQL Server MVP { Rozwiązałem Twój problem? Kliknij Rozwiązanie. Pomogłem Ci? kliknij Pomógł mi. }

Edytowano 1 raz. Ostatnio 2010-11-22 07:19:51 przez C3PO.

Pozdrawiam,
Paweł Potasiński

Łukasz Herman Ekspert WSS
Łukasz Herman
3540 pkt.
Guru
 
0


Ad 1. Nie mam dostępu do openrowset i podobnych - zablokowane.
Ad 2. O nieee. Poradziłem sobie lepiej. W DTSie jako bazę docelową wybrałem połączenie OleDB zamiast standardowego połączenia do MSSQL i mam polskie znaki.
Szybkością nie powala, ale działa.--

Paweł Potasiński Microsoft
Paweł Potasiński
7713 pkt.
Guru
 
0


Ad1. Zostaje linked server, o ile możesz go utworzyć :-) Względnie, można pokusić się o próbę przerzucenia tych danych z udziałem innego serwera, o ile jest z zewnątrz jakiś dostęp do docelowej instancji (wówczas możesz użyć np. DTS / Import-export Wizarda na innym serwerze jako destination pokazując serwer docelowy, a jako źródło owe nieszczęsne DBF-y).
Ad2. Cool, to była tylko propozycja ;-)
 --Pozdrawiam,Paweł Potasiński, SQL Server MVP { Rozwiązałem Twój problem? Kliknij Rozwiązanie. Pomogłem Ci? kliknij Pomógł mi. }

Pozdrawiam,
Paweł Potasiński

Łukasz Herman Ekspert WSS
Łukasz Herman
3540 pkt.
Guru
 
0


Postanowiłem zrobić wersję alternatywną, nie wymagającą sterownika VFP. Ale tu już jest problem z kodowaniem znaków.
Wzorując się twojej funkcji zacząłem przetwarzać dane. Ale u mnie kodu znaków źródłowych różnią się od tych u ciebie, ale już doszedłem do tego jak to pozmieniać.
 
Problem jest z tym, że kod:



[Kod]
CREATE FUNCTION [dbo].[ufn_MazoviaTo1250]
(
@String varchar(MAX)
)
RETURNS varchar(max)
WITH SCHEMABINDING
AS
BEGIN
SET @String = @String COLLATE Polish_BIN;
RETURN
REPLACE (
REPLACE (@String, CHAR(197), CHAR(234) -- ę=
), CHAR(229), CHAR(179) -- ł=
) COLLATE database_default;
END;





Dla dwóch znaków zwraca mi to samo. Wywołanie "SELECT dbo.ufn_MazoviaTo1250 ('Ĺĺ');" powinno zwrócić "ęł", a zwraca "ęę".WTF?--

PaSkol Ekspert WSS
PaSkol
628 pkt.
Senior
 
0


Postanowiłem zrobić wersję alternatywną, nie wymagającą sterownika VFP

Strasznie lakoniczne ;)
 
kodu znaków źródłowych różnią się od tych
 
VFox zazwyczaj zapisuje właśnie w kodowaniu CP1250, wersja dla Dos używała do tego CP850 (Latin II) i teraz gdyby wiadome było na czym polega Twoja wersja alternatywna, można by coś domniemywać. Jeśli przeszedłeś na Jet OLEDB, to tu jest jeszcze jeden problem - zakłada ono, że DBF jest w CP850, zamiast odczytywać stronę kodową z DBF-a co dla DBF-ów VFox-owych kończy się nieprawidłową interpetacją znaków narodowych (pojawiają się "krzaczki").
 
I tu właśnie dochodzimy do sedna - wypadałoby sprawdzić, jakie tak naprawdę kodowanie jest użyte w rzeczonym DBF-ie. W tym celu należy użyć jakiegoś podglądu HEX (podejrzewam, że ma go np. Total Commander) i sprawdzić 29-ty bajt pliku DBF (hex offset: 1D). Jego zawartość określa użytą stronę kodową, tj.:
 




Wartość Hex
Kod strony
Nazwa


01h
437
U.S. MS-DOS


02h
850
International MS-DOS


03h
1252
Windows ANSI


04h
10000
Standard Macintosh


64h
852
EE MS-DOS (Latin II)


65h
866
Russian MS-DOS


66h
865
Nordic MS-DOS


67h
861
Icelandic MS-DOS


68h
895
Kamenicky (Czech) MS-DOS


69h
620
Mazovia (Polish) MS-DOS


6Ah
737
Greek MS-DOS (437G)


6Bh
857
Turkish MS-DOS


96h
10007
Russian Macintosh


97h
10029
Eastern European Macintosh


98h
10006
Greek Macintosh


C8h
1250
Windows CE


C9h
1251
Russian Windows


CAh
1254
Turkish Windows


CBh
1253
Greek Windows


 
To powinno dać jakąś orientację. Niemniej sugerowałbym karmienie nas większą ilością informacji ;).
 
Tak naprawdę DBF (bodajże do wersji IV włącznie) jest plikiem tekstowym (liczby i daty są w nim zapisane tekstowo), który został poprzedzony binarną sekcją nagłówkową o zmiennej długości, zatem można jego translację wykonać jeszcze przed importem (trzeba tylko "przeskoczyć" przez nagłówek). Ja taką metodę stosowałem importują DBF-y z CP1250 do MSSQL-a: program importujący konwertował je na CP850, wrzucał do folderu dostępnęgo z MSSQL-a przez Linked Server, a MSSQL już to sobie w prosty sposób pobierał (i kodowanie od ręki miał prawidłowe, bo o to dbał Jet OLEDB).
--
PaSkol
Rozwiązałem Twój problem? Kliknij poniżej [Rozwiązanie].Jedynie Ci pomogłem? Kliknij [Pomógł mi].

Edytowano 1 raz. Ostatnio 2010-11-25 08:43:30 przez PaSkol.
Łukasz Herman Ekspert WSS
Łukasz Herman
3540 pkt.
Guru
 
0


 
Jeźeli chodzi o moją wersję alternatywną, to zauważyłem że Excel potrafi ładnie taki plik zaimportować na komputerze na którym nie ma sterownik Visual FoxPro (oczywiście bez polskich znaczków). Więc skopiowałem sobie connection stringa. Wygląda to teraz tak że łączę się poprzez ODBC korzystając z providera MSDASQL.
 
Kodowanie to już mogę sobie ręcznie poprawić, korzystając z ww. funkcji.
Problem w tym, że nawet jak odpalę ją przez



[Kod]
SELECT dbo.ufn_MazoviaTo1250 (char(197) + char(229));




To i tak konwertuje mi to jakbym przekazał dwa znaki char(197). Dlaczego?
Co do kodowanie zapisanego w pliku, to, ekhem, wartość wynosi 0 ;)
 
 --

PaSkol Ekspert WSS
PaSkol
628 pkt.
Senior
 
0


łączę się poprzez ODBC korzystając z providera MSDASQL.
 
Możesz tu wkleić connection string? Zawsze się czegoś nauczę.
 
Co do Twojego problemu to ponieważ konwersja jest ciągiem zagnieżdżonych wywołań Replace może się zdarzyć, że w przypadku pokrycia znaków (np.: CP1(ą)=CP2(ł) zaś CP1(ł)=CP2(ź)) dokonujesz podwójnej konwersji, czyli konwertujesz już znak przekonwertowany.
 
A może mógłbyś gdzieś na chwilę umieścić taki plik DBF - z chęcią mu się przyjrzę i może coś lepszego zapronuję (i jeszcze to 0 na offsecie 1dh)
 
--
PaSkol
Rozwiązałem Twój problem? Kliknij poniżej [Rozwiązanie].Jedynie Ci pomogłem? Kliknij [Pomógł mi].

Edytowano 1 raz. Ostatnio 2010-11-25 09:31:30 przez PaSkol.
Łukasz Herman Ekspert WSS
Łukasz Herman
3540 pkt.
Guru
 
0


Connection string wygląda paskudnie, ale działa:



[Kod]
"Provider=MSDASQL.1;Persist Security Info=False;Data Source=dBASE Files;Extended Properties="DSN=dBASE Files;DBQ=C:\;DefaultDir=C:\;DriverId=533;MaxBufferSize=2048;PageTimeout=5;";Initial Catalog=C:\;";




Plik: http://www.speedyshare.com/files/25368359/KATEGORI.DBF
--

Edytowano 1 raz. Ostatnio 2010-11-25 09:40:50 przez hermanluk.
PaSkol Ekspert WSS
PaSkol
628 pkt.
Senior
 
0


Proponuję jednak wrócić do sterownika Fox Pro, czyli taki connection string:
 



[Kod]
Provider=VFPOLEDB.1;Data Source=C:\




 
natomiast jako polecenia SQL służącego do pobrania danych należy użyć czegoś podobnego do poniższego (istotne jest to ChrTran konwertujące znaki z Mazovia, na CP1250):
 



[Kod]
select pred_col1, pred_col2, ChrTran(text_col, Chr(143)+Chr(149)+Chr(144)+Chr(156)+Chr(165)+Chr(163)+Chr(152)+Chr(160)+Chr(161)+Chr(134)+Chr(141)+Chr(145)+Chr(146)+Chr(164)+Chr(162)+Chr(158)+Chr(166)+Chr(167), 'ĄĆĘŁŃÓŚŹŻąćęłńóśźż') as text_col, succ_col1, succ_col2from plik_dbf




 
Sprawdziłem to na pliku, który wystawiłeś. BTW. Akurat potrzebował pliku indeksów, ale na to też jest sposób, trzeba wyzerować bajt na offsecie 1Ch.
 
Mam nadzieję, że to definitywnie rozwiążę Twój problem. BTW. Szkoda, że w MSSQL nie ma natywnie takiej fajnej funkcji jak ChrTran, która zamienia znak na znak na podstawie odpowiadających sobie pozycji z treści parametrów (można tak było także usuwać znaki - jeśli na odpowiadającej pozycji niczego nie było).
 
Oczywiście ChrTran działa tylko ze sterownikiem FoxPro.--PaSkol
Rozwiązałem Twój problem? Kliknij poniżej [Rozwiązanie].Jedynie Ci pomogłem? Kliknij [Pomógł mi].

Łukasz Herman Ekspert WSS
Łukasz Herman
3540 pkt.
Guru
 
0


W VisualFoxPro jest lepsza funkcja niż ChrTran.
Po prostu robię w selekcie CPCONVERT(620, 1250,kolumna) i mam dobre kodowanie.
Tylko że teraz rozglądam się jeszcze za alternatywą która nie będzie wymuszała instalacji dodatkowego sterownika, a najlepiej taką która domyślnie będzie działała na każdym serwerze.
Stąd kombinacje z innymi providerami.--

PaSkol Ekspert WSS
PaSkol
628 pkt.
Senior
 
0


W takim razie Microsoft.Jet.OLEDB.4.0 - jest zawsze i wszędzie. A przekodowania dokonywałbym przed importem DBF-a (tak jak robiłem zazwyczaj: pominięcie nagłówka i konwersja reszty) na tymczasowej jego kopii, za pomocą jakiegoś lepszego do tego celu języka programowania.--PaSkol
Rozwiązałem Twój problem? Kliknij poniżej [Rozwiązanie].Jedynie Ci pomogłem? Kliknij [Pomógł mi].

Łukasz Herman Ekspert WSS
Łukasz Herman
3540 pkt.
Guru
 
0


To teraz jeszcze pytanie dla Pawła dlaczego jego funkcja nie działa ;)
Raczej nie ma możliwości żeby coś się dwa razy konwertowało jeżeli uprościłem tą funkcję do zamiany tylko w przypadku dwóch znaków (patrz kod wyżej).--

PaSkol Ekspert WSS
PaSkol
628 pkt.
Senior
 
0


Rzecz w tym, że Jego funkcja działa. Natomiast nie działa dla kodowania jakie otrzymujesz (bo to nie jest kodowanie Mazovia). A otrzymujesz takie, ponieważ podczas pobierania DBF-a za pomocą dowolnego sterownika, ten dokonuje konwersji znaków narodowych z CP850 do CP1250. Problem w tym, że w DBF-ie to nie są znaki z zakresu CP850 tylko Mazovia. No i robi się totalna "kaszana".--PaSkol
Rozwiązałem Twój problem? Kliknij poniżej [Rozwiązanie].Jedynie Ci pomogłem? Kliknij [Pomógł mi].

Łukasz Herman Ekspert WSS
Łukasz Herman
3540 pkt.
Guru
 
0


Wykonuję taki kod:



[Kod]
DROP FUNCTION [dbo].[ufn_MazoviaTo1250]
CREATE FUNCTION [dbo].[ufn_MazoviaTo1250]
(
@String varchar(MAX)
)
RETURNS varchar(max)
WITH SCHEMABINDING
AS
BEGIN
SET @String = @String COLLATE Polish_BIN;
RETURN
REPLACE (
REPLACE (@String, CHAR(197), CHAR(234) -- ę=
), CHAR(229), CHAR(179) -- ł=
) COLLATE database_default;
END;

SELECT dbo.ufn_MazoviaTo1250 (char(197) + char(229));




Nie ma tu żadnych DBFów ani nic. Czysty SQL. Wynik jaki dostaję to "ęę", a powinno być "ęł".--

PaSkol Ekspert WSS
PaSkol
628 pkt.
Senior
 
0


Tak, ale to co podstawiasz, to jest efekt tego co odczytałeś z przekonwertowanych DBF-ów i to miałem na myśli.
 
Twój problem polega na tym, że tak naprawdę konwertujesz ten sam znak narodowy, pierwszy jest z wielkiej, a drugi z małej litery (jakieś "L" z akcentem [']). Prawdopodobnie przeszukiwanie nie jest wrażliwe na wielkość znaków i dlatego w pierwszym Replace zamienia Ci oba znaki (zamień miejscami Replace i będziesz miał 2 razy "ł").
 
P.S. Sztuczką cyrkową było odpowiedzieć na tę wiadomość - skoro nie widać już [Odpowiedz] ;).
--
PaSkol
Rozwiązałem Twój problem? Kliknij poniżej [Rozwiązanie].Jedynie Ci pomogłem? Kliknij [Pomógł mi].

Edytowano 1 raz. Ostatnio 2010-11-25 15:59:53 przez PaSkol.
PaSkol Ekspert WSS
PaSkol
628 pkt.
Senior
 
0


Podpinam się tutaj, bo wątek wcina się już zbyt głęboko i zaczynają być problemy z przyciskiem [Odpowiedz] w przypadku używania sekcji [Kod] (a nie zawaham się jej użyć ;) ).
Poniżej uniwersalna funkcja, która pozwala przekonwertować tekst wg dowolnego wzorca. W ramach testu wykonuję konwersję na tekst "polskawy" ;), tj. bez polskich znaków. Twój dwuznakowy przykład też zadziała. Widać, że funkcja nie jest wrażliwa na wielkość znaków. Dlaczego Twoja implementacja nie działała? Usuń z poniższego kodu "collate Polish_BIN", a efekt będzie taki sam jak u Ciebie.
 



[Kod]
if OBJECT_ID('dbo.ReplaceChars') is not null
drop function dbo.ReplaceChars;
GO
create function dbo.ReplaceChars(@Text varchar(max), @SearchingChars varchar(256), @Replacements varchar(256))
returns varchar(max)
as
begin
declare @Idx int = Len(@SearchingChars);
while @Idx > 0
begin
select
@Text = Replace(
@Text collate Polish_BIN,
SubString(@SearchingChars, @Idx, 1),
SubString(@Replacements, @Idx, 1)),
@Idx -= 1;
end;
return @Text;
end;
GO
-- Test
select
dbo.ReplaceChars(
'Zażółć gęślą jaźń, ZAŻÓŁĆ GĘŚLĄ JAŹŃ, zażółć gęślą jaźń',
'ĄĆĘŁŃÓŚŹŻąćęłńóśźż',
'ACELNOSZZacelnoszz');




 
Wydajność będzie najgorsza w porównaniu do propozycji z SQLGeek. No ale nie masz wyjscia, CLR-a (wg warunków jakie opisałeś) raczej nie zastosujesz.
--
PaSkol
Rozwiązałem Twój problem? Kliknij poniżej [Rozwiązanie].Jedynie Ci pomogłem? Kliknij [Pomógł mi].

Edytowano 1 raz. Ostatnio 2010-11-25 23:31:44 przez PaSkol.
PaSkol Ekspert WSS
PaSkol
628 pkt.
Senior
 
0


Acha. Jeszcze jedno gwoli uzupełnienia.
 
Paweł Potasiński miał tego pecha, że w Mazovii nie występuje nawet jedna para tych samych liter o różnej wielkości. Więc dla tego szczególnego przypadku jego funkcja działa poprawnie. Co ciekawe nie jest w niej w ogóle potrzebna linia:
 
SET @String = @String COLLATE Polish_BIN;
 
albowiem i bez niej kod zadziała. Wygląda bowiem na to, że REPLACE i tak konwertuje parametr wejściowy do collation zgodnego z bazą danych i trzeba mu je tam wymusić. Co ciekawe - wystarczy to zrobić raz, w najbardziej zagnieżdżonym REPLACE.
 
Gdyby przerobić funkcję Pawła na konwertującą z CP1250 na "polskawe" (czyli podmienić kody) - wówczas już nie zadziała prawidłowo (tj. nie przejdzie prawidłowo testu jaki zastosowałem dla swojej funkcji).--PaSkol
Rozwiązałem Twój problem? Kliknij poniżej [Rozwiązanie].Jedynie Ci pomogłem? Kliknij [Pomógł mi].

Łukasz Herman Ekspert WSS
Łukasz Herman
3540 pkt.
Guru
 
0


Dzięki. Działa świetnie :)--

Udziel odpowiedzi

pkt.
Treść wpisu:

Zaloguj się lub Zarejestruj się aby wykonać tę czynność.