Menu

Debugging SQL Express Client Sync Provider

How to finally get the SQL Express Client Sync Provider to work correctly? It’s been almost a year since it was released, and still it has documented bugs. One was detected by Microsoft more than a month after release and documented on the forum, but the fix was never included in the released version. We could analyze this kind of shameless negligence in the context of Microsoft's overall quality policies, but it’s a broad (and also well documented) topic, so we’ll leave it at that. It wouldn’t be such a problem if there were no people interested in using it, but there are, very much so. So, what else is there to do than to try to fix what we can ourselves… You can find the source for the class here. To use it, you may also want to download (if you don’t already have it) the original sql express provider source which has the solution and project files which I didn’t include. (UPDATE: the original source seems to be removed from the MSDN site, and my code was updated - see the comments for this post to download the latest version). The first (and solved, albeit only on the forum) problem was that the provider was reversing the sync direction. This happens because the client provider basically simulates client behavior by internally using a server provider. In hub-and-spoke replication, the distinction between client and server is important since only the client databases keep track of synchronization anchors (that is, remember what was replicated and when). I also incorporated support for datetime anchors I proposed in the mentioned forum post, which wasn’t present in the original source. But that is not all that’s wrong with the provider: it seems that it also swaps client and server anchors, and that is a very serious blunder because it’s very hard to detect. It effectively uses client time/timestamps to detect changes on the server and vice versa. I tested it using datetime anchors, and this is the most dangerous situation because if the server clocks aren’t perfectly synchronized, data can be lost. (It might behave differently with timestamps, but it doubt it). The obvious solution for anchors is to also swap them before and after running synchronization. This can be done by modifying the ApplyChanges method like this:

foreach (SyncTableMetadata metaTable in groupMetadata.TablesMetadata)
{
    SyncAnchor temp = metaTable.LastReceivedAnchor;
    metaTable.LastReceivedAnchor = metaTable.LastSentAnchor;
    metaTable.LastSentAnchor = temp;
} 

// this is the original line
SyncContext syncContext = _dbSyncProvider.ApplyChanges(groupMetadata, dataSet, syncSession); 

foreach (SyncTableMetadata metaTable in groupMetadata.TablesMetadata)
{
    SyncAnchor temp = metaTable.LastReceivedAnchor;
    metaTable.LastReceivedAnchor = metaTable.LastSentAnchor;
    metaTable.LastSentAnchor = temp;
}

This seems to correct the anchor confusion but for some reason the @sync_new_received_anchor parameter still receives an invalid value in the update/insert/delete stage, so it shouldn’t be used. The reason for this could be that both the client and server use the same sync metadata and that the server sync provider posing as client probably doesn’t think it is required to leave valid anchor values after it’s finished. I promise to post in the future some more information I gathered poking around the sync framework innards. Note that this version is by no means fully tested nor without issues, but its basic functionality seems correct. You have to be careful to use @sync_new_anchor only in queries that select changes (either that or modify the provider further to correct this behaviour: I think this can be done by storing and restoring anchors in the metadata during ApplyChanges, but I’m not sure whether this is compatible with the provider internal logic). Another minor issue I found was that the trace log reports both client and server providers as servers. If you find and/or fix another issue with the provider, please post a comment here so that we can one day have a fully functional provider.

Supporting triggers that occasionally generate values with NHibernate

NHibernate supports fields that are generated by the database, but in a limited way. You can mark a field as generated on insert, on update, or both. In this case, NHibernate doesn’t write the field’s value to the database, but creates a select statement that retrieves its value after update or insert.

Ok, but what if you have a trigger that updates this field in some cases and sometimes doesn’t? For example, you may have a document number that is generated for some types of documents, and set by the user for other types. You cannot do this with NHibernate in a regular way – but there is a workaround…

It is possible to map multiple properties to the same database column. So, if you make a non-generated property that is writable, and a generated read-only property, this works. You have to be careful, though, because the non-generated property’s value won’t be refreshed after database writes.

A more secure solution would be to make one of the properties non-public and implement the other one to support both functionalities. Like this:

//
// This field is used only to send a value to the database trigger:
// the value set here will be written to the database table and can be consumed by
// the trigger. But it will not be refreshed if the value was changed by the trigger.
// 
private int? setDocumentNumber;	

private int? _documentnumber;

//
// The public property that works as expected, generated but not read-only
// public int? DocumentNumber { get { return _documentnumber; } set { // NHibernate is indifferent to this property's value (it will not // be written to the database), so we have to update the setDocumentNumber // field which is regularly mapped _documentnumber = value; setDocumentNumber = value; } }

Here’s the NHibernate mapping for these two:

<property name="DocumentNumber" generated="always" insert="false" update="false"/>
<property name="setDocumentNumber" column="DocumentNumber" access="field"/>

Rešenja po zahtevima klijenta

Najveća vrednost firme je stručnost: poznavanje posla i tržišta, znanje i procesi koji su usavršavani godinama. Međutim, kada je potrebno da softver to podrži nastaje ogroman problem jer programi su u suštini najčešće nefleksibilni. Aplikacije se prave da rade na određeni način, onako kako stručnjaci softverske kuće misle da je najbolje raditi posao. Gotova rešenja - čak i njihovo ime govori o tome da je tu priča prilično završena - su ili jeftina "univerzalna" rešenja koja implementiraju nekakvu neutralnu sredinu funkcionalnosti, ili skupi sistemi koji  forsiraju "best practice", dakle nešto što većina smatra da je najbolji način. Firma koja želi da softverski podrži svoje poslovanje je često svedena na tri opcije: da kupi jeftino "standardno" rešenje (koje najčešće pokriva samo knjigovodstvo ili se najviše koncentriše na njega), da kupi veliki ERP (koji je vrlo skup) ili da pravi sebi rešenje "od nule".

EDI ukratko

Šta je EDI?

EDI (Electronic Data Interchange) je standard za komunikaciju između informacionih sistema. Kao što e-mail omogućava razmenu informacija među ljudima, tako EDI prenosi informacije koje razumeju informacioni sistemi. Njegovim uvođenjem se eliminiše potreba za slanjem dokumenata faksom ili poštom i njihovim prekucavanjem, čime nestaje jedna cela kategorija problema i nesporazuma i štedi se na troškovima. Suština je jednostavna: ako jedna firma u svom sistemu kreira, recimo, porudžbinu za drugu firmu, ta porudžbina će se pojaviti u sistemu druge firme. pročitaj više...

EDIFACT i konverzija

U EDI komunikaciji je kao i u e-mail razmeni potrebno ili da oba učesnika razumeju isti jezik ili da postoji prevodioc. Najrasprostaranjeniji "zajednički jezik" za EDI je standard EDIFACT koji je definisan da pokrije što širi spektar upotreba i samim tim je relativno komplikovan. Eight Bit i e-Integration kao EDI provajder  nude svojim korisnicima standardno i uslugu prevodioca: ako korisnik već ima mogućnost da prima ili šalje dokumente u određenom formatu, postoji opcija pravljenja konverzije iz tog formata u EDIFACT. Konvertor se ugrađuje u EDI kliring centar i u tom trenutku korisnik može da razmenjuje tu vrstu dokumenta sa bilo kojim drugim EDI korisnikom povezanim na bilo kog EDI provajdera.

Vrste dokumenata

EDIFACT standard podržava veliki broj različitih poslovnih dokumenata. U svetu se najviše razmenjuju porudžbine, otpremnice i fakture i to je za veliku većinu korisnika dovoljno. Od ostalih tipova dosta su zastupljeni cenovnici, izveštaji o prodaji kao i inventar liste, a postoje i poruke koje automatizaciju dovode do najvišeg nivoa, kao što su na primer poruke za potvrdu prijema robe, promenu porudžbine, najavu isporuke, plaćanja, itd. U razmeni se retko koriste sve mogućnosti koje određena poruka pruža već se prenose samo neophodne informacije, što dodatno olakšava povezivanje. (Na primer, u određene vrste poruka moguće je smestiti različite logističke podatke koji definišu način transporta a koji većini korisnika nisu neophodni). pročitaj više...

Koristi

Samim tim što sistemi komuniciraju bez intervencije ljudi postiže se veća udobnost i pouzdanost u radu. Krajnji korisnici sistema i dalje mogu da vide sadržaj dokumenata u samoj aplikaciji, ali više nije potrebno da ih oni unose u sistem ili šalju putem mail-a, faksa i tome slično. Ovim se ostvaruje ne samo ušteda na vremenu potrošenom na prekucavanje već i zbog eliminacije kako grešaka tako i nesporazuma: ono što jedan EDI korisnik pošalje, garantovano se pojavljuje kod primaoca. S obzirom da je prosečna pretplata za EDI konekciju reda veličine prosečne pretplate za internet konekciju, jasno je da je i novčana ušteda prilična. pročitaj više...

Kako se povezati?

Povezivanje na EDI je relativno jednostavno: najveći zahvat je modifikacija korisnikovog informacionog sistema da podrži prijem ili slanje određene vrste dokumenata - a i to je neophodno samo ako podrška već nije prisutna. Poruke se primaju i/ili šalju u vidu fajlova koji se razmenjuju sa e-Integration EDI kliring centrom. Naša preporuka je da klijent instalira našu AS2 klijentsku aplikaciju koja ovu razmenu potpuno automatizuje, a osim toga je i najsigurniji i najpouzdaniji način komunikacije. Fajlovi mogu sadržati podatke u proizvoljnom formatu, a najbrža i najjeftinija opcija je da se koristi neki od formata čiju konverziju e-Integration podržava: mi u te svrhe preporučujemo korišćenje eRDS formata koji je kranje jednostavan. Najčešće se za početak uvodi jedan tip dokumenta, i u velikoj većini slučajeva su to upravo porudžbine, koje su po strukturi i najjednostavnije. pročitaj više...

Pouzdanost

e-Integration EDI serveri nalaze se u prostorijama Level 3 provajdera u Dizeldorfu koji je jedan od većih internet provajdera u Evropi. Za svaku od celina sistema sistema postoje rezervni serveri spremni da preuzmu funkciju ako primarni zataji, a takođe postoji kopija kompletnog sistema na rezervnoj lokaciji u prostorijama e-Integration-a u Ratingenu. Sa ovako postavljenom infrastrukturom praktično je nemoguće da dođe do prekida u radu, i dostupnost servera je 99,99%. Ipak, i pored toga, firma poseduje i osiguranje protiv eventualne štete nastale na strani korisnika zbog gubitka podataka.

Dodatne usluge

EightBit i e-Integration nude klijentima vrlo širok spektar usluga. U oblasti EDI razmene podataka praktično sve vrste komunikacije su podržane, od konverzija u i iz različitih formata podaka kao što su Excel i PDF preko starijih digitalnih kanala komunikacije kao što je X.400 pa sve do faksa i pošte... Podvlačimo da je u slučaju Excel i PDF fajlova kao i faksa podržana dvosmerna komunikacija, dakle i slanje i prijem: ako vaš partner ima mogućnost da šalje samo faksove ili PDF-ove te informacije svejedno mogu da prođu kroz e-Integration clearing centar i da se pojave u vašem sistemu kao standardna EDI poruka. Kao proširenje usluge razmene podataka, e-Integration nudi i uslugu digitalnog potpisa i arhiviranja dokumenata, s obzirom da je takođe zvanični sertifikacioni autoritet.

Sa svoje strane, EightBit zaokružuje sliku time što se koncentriše na lokalni, "in house" aspekt poslovanja: s obzirom da je naša primarna orijentacija razvoj poslovnih informacionih sistema, u mogućnosti smo da upotpunimo EDI rešenja izradom funkcionalnosti koje su potrebne na samoj lokaciji klijenta. Bilo da je u pitanju podrška kompletnom poslovanju (u kom slučaju nudimo naše gotove ERP/CRM aplikacije) ili dopuniti funkcionalnost postojećeg sistema (npr. implementirati B2B ili B2C web portal za partnere koji nisu EDI povezani ili uraditi samo neki aspekt razmene podataka), EightBit poseduje iskustvo i tehničko znanje da na  visokokvalitetan način ispuni i najteže zahteve.

EDI Reference

Nemačka kompanija e-Integration je jedan od najvećih EDI provajdera u Evropskoj Uniji, firma koja je kao nekadašnji deo Dojče post bila pionir u razvoju EDI i čiji stručnjaci su učestvovali u definisanju samog standarda. Na teritoriji EU, SAD i Kanade e-Integration ima oko 6.500 povezanih firmi. Među za nas poznatijim klijentima nalaze se Metro Group, DM, British Petrol, Siemens, DHL, Lidl, Kuehne & Nagel, Karstadt, Vaillant, Unilever, Springer, itd...

Subscribe to this RSS feed