Legutóbbi bejegyzésemben földig leoltottam kb a zsírparaszt visual studiot és az sql ce-t.
Azóta sikerült lehetőleg még jobban elmélyednem a témában, és bár van benne egy-két nagyon hiányzó és fájó pont, azért bizonyos dolgokban végül egész pofás kis megoldásokkal elő lehet állni, csak tudni kell hogy.
Ennek illusztrálására most álljon itt két kis kódrészlet:
public static DataTable KeresCikket(string parameter)
{
CikkTableAdapter cta = new CikkTableAdapter();
DSCikk.CikkDataTable cdt = cta.GetData();
DataRow[] cikkrows = cdt.Select("Ean like '%" + parameter + "%' OR Ean like '%" + parameter + "%' OR Megnev like '%" + parameter + "%'");
DataTable result = new DataTable();
result = cdt.Clone();
foreach (DataRow cikkrow in cikkrows)
{
result.ImportRow(cikkrow);
}
return result;
}
ÉS!:
public static DataTable KeresCikket(string parameter)
{
DSCikk.CikkDataTable cdt = DataAdapters.cta.GetDataByLikeParam(parameter);
return cdt;
}
Na kitaláljátok-e... igen. ez a kettő bizony kőugyanazt csinálja. Utóbbi megoldásban egyedül egy amúgy szépen kattintgatással is összerakható SQL query fut... Jó dolog így végignézni, hogy mit disznólkodtam én régebben a projektekben, nagyon sokat lehet szépíteni a kódon. Viszont joggal tehetjük fel a kérdést, hogy teljesítményben ez hogyan jelenik meg. Ezen a ponton lepődtem én meg: az utóbbi metódus kb 3szor gyorsabban le is fut azonos eredményt hozva... most keresem, hol malackodtam még... NEMFÉLREÉRT!
...
Na mondjuk az igaz, hogy vicces megoldást találtam a bluetoothon keresztüli fájlok küldésére (szekvenciálisan). Van egy nagyon jópofa kis keretrendszer az ilyen dolgok hegesztésére: http://32feet.net/ oldalon találhattok hozzá egy egész aktív fórumot, meg sok segítséget. Ráadásul ingyenes.
Igaz, néha kicsit szenvedni kell, mert az oké, hogy addig nem lehet a következő file-t elküldeni, amíg az előző át nem ért, mert a kapcsolaton addig csak egy "BadRequest" üzenet jön vissza, de valamiért nálam ez itt be is ragadt szépen rendesen. Visszafejtettem: a program bár a kapcsolatot lezárta, de a socketet nem szabadította fel, így az beragadt, és az első file leküldése után csak bambult mint GDF-es villanymérnök az oszcilloszkópra. Az, hogy implicit várakozást adunk meg, nem jó megoldás, mert nem tudjuk mikor ér át a file. Az meg milyen paraszt már, ha érted beadod neki hogy várjá fél órát azt addig biztos átmegy, utána mehet a többi. A socketet felszabadítani nem tudtam sajnos, mert mindenhol valami nagy piros pöttyös exceptiont dob a kis gané. Megoldás?
...
...
elment rá két napom, de megmutatom okulásul...:
file küldése után [repeat until nem sikerül a következő file küldése]:
AppSettings.BTRadio.Mode = InTheHand.Net.Bluetooth.RadioMode.PowerOff;
Thread.Sleep(5000);
AppSettings.BTRadio.Mode = InTheHand.Net.Bluetooth.RadioMode.Discoverable;
Igen. Jól látod. Kikapcsolom a kicseszett kékfogat az egész telefonon, várok 5 mp-t és visszakapcsolom.... :D Na így próbálja meg foglaltba tartani a socketet, hogy "driverből" kilövöm alóla az egészet...
~~~
A következő címkéjű bejegyzések mutatása: munka. Összes bejegyzés megjelenítése
A következő címkéjű bejegyzések mutatása: munka. Összes bejegyzés megjelenítése
2011/04/01
SQL CE én így szeretlek...
Ez zseniális... (egyben tutorial / mesemesemeskete azoknak, akiknek valaha szükségük lesz táblaátnevezésre SQL CE-ben VS2008 alattt...)
Visual Studio 2008-ban, SQL CE-t konfigolva döbbenhetünk rá arra a csodálatos tényre, hogy oly bonyolult műveletek végrehajtására, mint pl... egy tábla ÁTNEVEZÉSE nincs alapból mód. Ugyanis a tábla tulajdonságainál a Name mező ki van szürkítve, csak olvasható, tehát nem tudod átírni, bármennyire is próbálkozol, és még csak elrejtve sincsen a környezetben ilyen funkció. Magyarán mintha a VS2008 nem ismerné az ALTER TABLE NAME c. részt... vagyis inkább az SQL CE nem ismeri ezt.
Mit is tegyél, márpediglen, ha mégis át kell nevezni egy táblát? Ilyenkor jön jól egy kis T-SQL. Na meg egy kis röhögés...
Futtassunk csak egy query-t, névszerint egy sp_rename-t.
Majd futtatás után rökönyödjünk meg, csalódjunk, essünk pofára, amiért ilyet kapunk:
Igen, jól látod, hibaüzi, hogy Unable to parse query text. Azaz, hogy képtelen értelmezni/lefordítani azt a szájbatekert queryt, tehát nem tudja, mi az az sp_rename... gondolnád te. Viszont ott egy continue gomb...
... ezt kapod, ha rákattintasz. WTF?!!!!! Nyomjunk egy refresht a táblákra...
... na erre varjál gombot. Visual studio 2008, SQL Compact Edition, Micro$oft. Én így szeretlek.
btw, szerinted az normális, hogy egy ilyen "bonyolult" művelethez T-SQL-t kell tudni? ... hány "programozó" cseszett el vajon órákat, hogy mezőnként átmásolt táblákat egy új táblába.... nocomment.
~~~
Visual Studio 2008-ban, SQL CE-t konfigolva döbbenhetünk rá arra a csodálatos tényre, hogy oly bonyolult műveletek végrehajtására, mint pl... egy tábla ÁTNEVEZÉSE nincs alapból mód. Ugyanis a tábla tulajdonságainál a Name mező ki van szürkítve, csak olvasható, tehát nem tudod átírni, bármennyire is próbálkozol, és még csak elrejtve sincsen a környezetben ilyen funkció. Magyarán mintha a VS2008 nem ismerné az ALTER TABLE NAME c. részt... vagyis inkább az SQL CE nem ismeri ezt.
Futtassunk csak egy query-t, névszerint egy sp_rename-t.
sp_rename [réginév], [újnév]
Pl. így
... na erre varjál gombot. Visual studio 2008, SQL Compact Edition, Micro$oft. Én így szeretlek.
btw, szerinted az normális, hogy egy ilyen "bonyolult" művelethez T-SQL-t kell tudni? ... hány "programozó" cseszett el vajon órákat, hogy mezőnként átmásolt táblákat egy új táblába.... nocomment.
~~~
2010/04/29
IM.XML 1
Ez csak egy jegyzet saját magam számára, ill. azoknak akik esetleg belefutnának még ilyen hibaüzenetbe, azoknak tanulságként szolgálhat.
Az cégnél, akiknek dolgozom, lehetősége van minden ügyfélnek arra, hogy XML file-okat egy oldalra feltöltve, a cégtől termékinformációt, rendeléseket, vagy akár számlaadatokat kapjanak meg. Azonban eddig erre semmi átfogó megoldás nem volt, mivel a cég csak az interfészt és a szolgáltatást adta, program nem volt, ami ezt megfelelően ki is használta volna. Azonban a tesztelés, és újabban az egyre több ilyen jellegű felkérés miatt, úgy gondoltam, hogy érdemes lenne csinálni egy kis progit, amivel tudom én magam is tesztelni a rendszer működését.
Így kerültem kapcsolatba azzal, hogy az MSXML 2.4es verzió megkerülésével, C# alapon hogyan is lehetne csinálni web-es feltöltést, és utána válaszfeldolgozást. Nos összerittyentettem gyorsan egy kis felületet, ahol a kedves felhasználó beírja a usn/psw párost, és PNArequestet (készlet és ár információ) tud küldeni, amennyiben tudja a termék sku-ját és mennyiségét.
Magát az XML file-t nem is generálom le, egyszerűen egy stringbe íratom az egészet, amit egy külön osztályban tárolok. Ez nem a legjobb megoldás, mivel korlátos, de tesztelésre pont elegendő.
na de nem ezért írtam blogbejegyzést, hanem maga a feltöltés miatt: elkövettem ugyanis egy pár hibát.
HttpWebRequest xmlRequest = (HttpWebRequest)WebRequest.Create("https://im-xml.com/receiveXML.ASP");
Ez még jónak tűnik, de a későbbiekben meglátjuk, hogy helytelen...
xmlRequest.Method = "POST";
xmlRequest.ContentType = "text/xml";
byte[] xmlByteStream = Encoding.UTF8.GetBytes(rtbXMLText.Text);
Stream xmlStream = xmlRequest.GetRequestStream();
xmlStream.Write(xmlByteStream, 0, xmlByteStream.Length);
xmlStream.Close();
Ez meg maga a küldésért felelős rész. Beállítom, hogy POST típusú tranzakciót, azaz küldést követnék el, méghozzá "text/xml" típusú tartalommal, majd a kis xml file-ocskám szövegét UTF8as kódolású byte tömbbé konvertálom. Miért ezzé? Mert ezt lehet megadni egy Streamnek bemenetnek, amivel majd feltöltöm a webhelyre :) (persze ekkor még jóhiszeműen gondoltam, hogy így fel lehet... :-)) végül lezárom a streamet és kész.
Hogy hol hibádzott a dolog? több helyen is.
A hibaüzenet az volt, hogy "Cannot send a content-body with this verb-type". És a stream létrehozásánál akadt meg. Ez a hibaüzi elvileg olyankor jön elő, ha mondjuk GET-tel szeretnél küldeni, viszont itt a Method jól láthatóan POST volt. Hol van tehát a hiba? ...
Kutakodás, és nem kevés baráti segítség (Kösz Boo :-)) árán végül sikerült megoldani a helyzetet. A hiba kétrétű volt:
string uri = "https://im-xml.com/receiveXML.asp";
WebRequest xmlreq = WebRequest.Create(uri);
xmlreq.Method = "POST";
xmlreq.ContentType = "text/xml";
StreamWriter srw = new StreamWriter(xmlreq.GetRequestStream());
srw.WriteLine(xth.GetXMLText());
srw.Close();
ahol az xth.GetXMLTest() csak az XML stringet adja vissza. A feltöltés így már rendben lefut, a szerver válaszol, egy egyszerű StreamReaderes kis játékkal ki is lehet olvasni:
WebResponse xmlrsp = xmlreq.GetResponse();
StreamReader srr = new StreamReader(xmlrsp.GetResponseStream());
string fullresponse = srr.ReadToEnd();
Most már csak a kedves felhasználó jogait, akinek a nevében küldöm kell megnézzem, hogy a szerverről ne egy hibaüzi jöjjön vissza... :-)
Tanulságul szolgáljon mindazoknak, akik beleütköznek ilyen hibába esetleg, és hogy használj StreamReadert/Writert sima Stream helyett.
~~~
Az cégnél, akiknek dolgozom, lehetősége van minden ügyfélnek arra, hogy XML file-okat egy oldalra feltöltve, a cégtől termékinformációt, rendeléseket, vagy akár számlaadatokat kapjanak meg. Azonban eddig erre semmi átfogó megoldás nem volt, mivel a cég csak az interfészt és a szolgáltatást adta, program nem volt, ami ezt megfelelően ki is használta volna. Azonban a tesztelés, és újabban az egyre több ilyen jellegű felkérés miatt, úgy gondoltam, hogy érdemes lenne csinálni egy kis progit, amivel tudom én magam is tesztelni a rendszer működését.
Így kerültem kapcsolatba azzal, hogy az MSXML 2.4es verzió megkerülésével, C# alapon hogyan is lehetne csinálni web-es feltöltést, és utána válaszfeldolgozást. Nos összerittyentettem gyorsan egy kis felületet, ahol a kedves felhasználó beírja a usn/psw párost, és PNArequestet (készlet és ár információ) tud küldeni, amennyiben tudja a termék sku-ját és mennyiségét.
Magát az XML file-t nem is generálom le, egyszerűen egy stringbe íratom az egészet, amit egy külön osztályban tárolok. Ez nem a legjobb megoldás, mivel korlátos, de tesztelésre pont elegendő.
na de nem ezért írtam blogbejegyzést, hanem maga a feltöltés miatt: elkövettem ugyanis egy pár hibát.
HttpWebRequest xmlRequest = (HttpWebRequest)WebRequest.Create("https://im-xml.com/receiveXML.ASP");
Ez még jónak tűnik, de a későbbiekben meglátjuk, hogy helytelen...
xmlRequest.Method = "POST";
xmlRequest.ContentType = "text/xml";
byte[] xmlByteStream = Encoding.UTF8.GetBytes(rtbXMLText.Text);
Stream xmlStream = xmlRequest.GetRequestStream();
xmlStream.Write(xmlByteStream, 0, xmlByteStream.Length);
xmlStream.Close();
Ez meg maga a küldésért felelős rész. Beállítom, hogy POST típusú tranzakciót, azaz küldést követnék el, méghozzá "text/xml" típusú tartalommal, majd a kis xml file-ocskám szövegét UTF8as kódolású byte tömbbé konvertálom. Miért ezzé? Mert ezt lehet megadni egy Streamnek bemenetnek, amivel majd feltöltöm a webhelyre :) (persze ekkor még jóhiszeműen gondoltam, hogy így fel lehet... :-)) végül lezárom a streamet és kész.
Hogy hol hibádzott a dolog? több helyen is.
A hibaüzenet az volt, hogy "Cannot send a content-body with this verb-type". És a stream létrehozásánál akadt meg. Ez a hibaüzi elvileg olyankor jön elő, ha mondjuk GET-tel szeretnél küldeni, viszont itt a Method jól láthatóan POST volt. Hol van tehát a hiba? ...
Kutakodás, és nem kevés baráti segítség (Kösz Boo :-)) árán végül sikerült megoldani a helyzetet. A hiba kétrétű volt:
- HttpWebRequest nem XML küldésre való. Sima WebRequestet kell alkalmazni ilyenkor
- A kódolási mizéria elkerülése érdekében a direkt Stream helyett lehet StreamWritert is használni - sokkal egyszerűbb, kezelhetőbb.
string uri = "https://im-xml.com/receiveXML.asp";
WebRequest xmlreq = WebRequest.Create(uri);
xmlreq.Method = "POST";
xmlreq.ContentType = "text/xml";
StreamWriter srw = new StreamWriter(xmlreq.GetRequestStream());
srw.WriteLine(xth.GetXMLText());
srw.Close();
ahol az xth.GetXMLTest() csak az XML stringet adja vissza. A feltöltés így már rendben lefut, a szerver válaszol, egy egyszerű StreamReaderes kis játékkal ki is lehet olvasni:
WebResponse xmlrsp = xmlreq.GetResponse();
StreamReader srr = new StreamReader(xmlrsp.GetResponseStream());
string fullresponse = srr.ReadToEnd();
Most már csak a kedves felhasználó jogait, akinek a nevében küldöm kell megnézzem, hogy a szerverről ne egy hibaüzi jöjjön vissza... :-)
Tanulságul szolgáljon mindazoknak, akik beleütköznek ilyen hibába esetleg, és hogy használj StreamReadert/Writert sima Stream helyett.
~~~
Feliratkozás:
Bejegyzések (Atom)