Legacy programma decompilen, voor regelwijziging [Win32]

[Sjoerd_r]

Beste allemaal,

Wellicht voor jullie gesneden koek maar voor mij als noob verschrikkelijk lastig, ik zal het even uitleggen:

Op het werk werken wij met een ERP systeem Kerredige Wholesale, hiermee regelen wij al onze boekhoudkundige zaken en verwerken we ook de orders. Hiernaast hebben we een los programmatje die uit de database van Wholesale de adres gegevens haalt van de klant om een label te printen, na een update van Kerredige wholesale werkt ons programma voor het maken van labels niet meer, foutmelding is dat er een tabel in de database niet meer te vinden is. Ik weet welke tabel het is en hoe hij nu na de update genoemd is.

Het programmatje om de labels te printen is destijds speciaal voor ons geschreven en er valt in de UI niks aan in te stellen. Als ik het programma bekijk met JetBrains dotPeek kan ik de regel vinden van tabel uit de database die hij zoekt. Nu wil ik die regel bewerken met de nieuwe naam die in die database gewijzigd is, maar dat lukt dus niet.

Ik weet dus waar ik naar moet kijken en wat ik moet wijzigen maar ik weet alleen niet hoe...

Relevante software en hardware die ik gebruik
Windows 11
Kerredige Wholesale
Multivers Extended shipping

Wat ik al gevonden of geprobeerd heb:
De regel voor het aanspreken van de juiste database heb ik al gevonden, nu nog wijzigen...

Helaas werkt de consultant meer als IT'er en is hij ook niet te bereiken.

Hieronder de regel die gewijzig moet worden:
DataTable dataTable5 = new DataTable("adres");
new OdbcDataAdapter(string.Format("SELECT ba012.adres , ba012.adresdelen , ba011.cdiso AS CDLAND , ba011.naamlandint , ba012.cdadsdef FROM PUB.\"ba-012\" ba012 LEFT OUTER JOIN PUB.\"ba-011\" ba011 ON ba011.cdland = ba012.cdland WHERE ba012.\"id-cdads\" = '{0}' ", RuntimeHelpers.GetObjectValue(row1["CDADRES"])), mdlAlgemeen.odbcMultivers).Fill(dataTable5);
if (dataTable5.Rows.Count >= 1)
{

ba012.adres moet worden: ba012.oldadres en ba012.adresdelen moet worden ba012oldadresdelen

Onderstaand de foutmelding van het programma zoals het nu is:



Graag jullie advies

[RobIII]

Dat wordt een lastige; idealiter was de tabelnaam even lang of korter; nu moet je ergens ruimte zien te creëren voor die extra karakters.

Je kunt met een hexeditor proberen de query aan te passen naar iets als

SQL:

--before
SELECT ba012.adres , ba012.adresdelen , ba011.cdiso AS CDLAND , ba011.naamlandint , ba012.cdadsdef FROM PUB."ba-012" ba012 LEFT OUTER JOIN PUB."ba-011" ba011 ON ba011.cdland = ba012.cdland WHERE ba012."id-cdads" = '{0}'

--after
SELECT a.oldadres as adres, a.oldadresdelen as adresdelen, b.cdiso AS CDLAND, b.naamlandint, a.cdadsdef FROM PUB."ba-012" a LEFT OUTER JOIN PUB."ba-011" b ON b.cdland = a.cdland WHERE a."id-cdads" = '{0}'

Rest aanvullen met spaties.

De crux is dat je 't liefst de query exact even lang houdt, dus ik heb wat onnodige spaties her-en-der verwijderd. De "OUTER" kan er ook nog uit en zo valt er nog wel e.e.a. te moffelen.

Ik weet verder niet welk RDBMS je gebruikt, maar je zou ook een 'computed column' met de oude naam kunnen toevoegen die de waarde uit 'old...' spiegelt. Maar daar wordt je ERP misschien niet vrolijk van en zou ik het niet op wagen.

[ Voor 38% gewijzigd door RobIII op 13-05-2024 15:02 ]

[Sjoerd_r]

RobIII schreef op donderdag 9 mei 2024 @ 11:38:
Dat wordt een lastige; idealiter was de tabelnaam even lang of korter; nu moet je ergens ruimte zien te creëren voor die extra karakters.

Je kunt met een hexeditor proberen de query aan te passen naar iets als

SQL:

--before
SELECT ba012.adres , ba012.adresdelen , ba011.cdiso AS CDLAND , ba011.naamlandint , ba012.cdadsdef FROM PUB.\"ba-012\" ba012 LEFT OUTER JOIN PUB.\"ba-011\" ba011 ON ba011.cdland = ba012.cdland WHERE ba012.\"id-cdads\" = '{0}'

--after
SELECT ba012.oldadres, ba012.oldadresdelen, ba011.cdiso AS CDLAND, ba011.naamlandint, ba012.cdadsdef FROM PUB.\"ba-012\" ba012 LEFT OUTER JOIN PUB.\"ba-011\" ba011 ON ba011.cdland = ba012.cdland WHERE ba012.\"id-cdads\"='{0}'

Edit: Oh, wacht, dit gaat niet werken. Je moet ook nog "as adres" en "as adresdelen" erin zien te moffelen...

De crux is dat je 't liefst de query exact even lang houdt, dus ik heb wat onnodige spaties her-en-der verwijderd. De "OUTER" kan er ook nog uit en zo valt er nog wel e.e.a. te moffelen.

Ik weet verder niet welk RDBMS je gebruikt, maar je zou ook een 'computed column' met de oude naam kunnen toevoegen die de waarde uit 'old...' spiegelt. Maar daar wordt je ERP misschien niet vrolijk van en zou ik het niet op wagen.

Dank voor je antwoord! je bent me echter al helemaal kwijt

Ik had gehoopt dat er een simpele oplossing bestond, iets van gewoon de naam wijzigen, opslaan en klaar. Maar het is iets ingewikkelder dus

Altijd fijn die updates waardoor je oude meuk niet meer werkt.

[Rukapul]

Let trouwens even op of de 'old' tabellen bij mutaties de nieuwe informatie bevatten. Het kan ook zijn dat het alleen de informatie bevat van voor de aanpassing aan de database.

In dat geval staat de courante data in een andere tabel.

[RobIII]

Sjoerd_r schreef op donderdag 9 mei 2024 @ 11:47:
Dank voor je antwoord! je bent me echter al helemaal kwijt

1. Maak eerst een backup/reservekopie van de oude executable die je gaat aanpassen.
2. Download een gratis hex-editor.
3. Open de executable met die hex-editor
4. Zoek de query in je executable
5. Pas de query aan zoals aangegeven
6. Sla op
7. Probeer

[ Voor 12% gewijzigd door RobIII op 09-05-2024 11:51 ]

[Sjoerd_r]

Rukapul schreef op donderdag 9 mei 2024 @ 11:49:
Let trouwens even op of de 'old' tabellen bij mutaties de nieuwe informatie bevatten. Het kan ook zijn dat het alleen de informatie bevat van voor de aanpassing aan de database.

In dat geval staat de courante data in een andere tabel.

Dit schijnt de wijziging te zijn:

[Rukapul]

Sjoerd_r schreef op donderdag 9 mei 2024 @ 11:47:
[...]


Dank voor je antwoord! je bent me echter al helemaal kwijt

Ik had gehoopt dat er een simpele oplossing bestond, iets van gewoon de naam wijzigen, opslaan en klaar. Maar het is iets ingewikkelder dus

Altijd fijn die updates waardoor je oude meuk niet meer werkt.

Rob's oplossing is simpel als je het doorhebt.

Je hebt alleen hex editor nodig. Daar kun je de query string aanpassen terwijl de rest ongewijzigd blijft. Je kunt de nieuwe query er zo overheen plakken zolang de nieuwe maar even lang is als de oude.

[Sjoerd_r]

Er is ( mijn inziens ) wel genoeg ruimte in de regel om het aan te passen, of denk ik nu te simpel:

[RobIII]

Sjoerd_r schreef op donderdag 9 mei 2024 @ 11:52:
Er is ( mijn inziens ) wel genoeg ruimte in de regel om het aan te passen, of denk ik nu te simpel:
[Afbeelding]

Dat gaat niet in de decompiled versie, die moet je dan her-compilen en als dat al werkt is de kans groot dat 't ergens stuk is.

Je wil een hex-editor gebruiken. Ik gebruik zelf deze maar die betaal ik braaf; geen idee of de trial versie limitaties heeft mbt. opslaan o.i.d. Maar er zijn zat gratis alternatieven te vinden met een beetje google-moeite.

[ Voor 19% gewijzigd door RobIII op 09-05-2024 11:56 ]

[IceM]

Je zou kunnen kijken of het met dnSpy lukt. Dat is een .net assembly debugger maar kan ook wijzigingen recompilen. Het is al oud, maar aangezien je executable ook vrij oud lijkt is het een poging waard.

[alex3305]

Je zou in plaats daarvan ook nog dnSpy kunnen proberen.

Maar inderdaad, zorg wel voor een backup voor je begint .

[vistu]

Is t geen optie een view te maken naar de nieuwe tabel met de oude naam? Of gaat dat qua naamgeving mis?

[Sjoerd_r]

Dank allemaal, ik ga het proberen met de gegeven opties. Het is geen probleem om er een paar honderd euro tegenaan te gooien voor een hex editor een nieuwe oplossing gaat vele malen meer kosten.

Ik heb de exacutable op een stickje staan om mee te prutsen, is maar 242kB groot

Mocht het onverhoopt toch mis gaan, dan tja... Het werkt nu ook al niet

[RobIII]

Sjoerd_r schreef op donderdag 9 mei 2024 @ 12:13:
Dank allemaal, ik ga het proberen met de gegeven opties. Het is geen probleem om er een paar honderd euro tegenaan te gooien voor een hex editor een nieuwe oplossing gaat vele malen meer kosten.

Dat is nergens voor nodig. Er zijn gratis alternatieven die exact dezelfde (basis) functionaliteit hebben.

Sjoerd_r schreef op donderdag 9 mei 2024 @ 12:13:
Mocht het onverhoopt toch mis gaan, dan tja...

...heb ik nog altijd de reservekopie van de executable.

Gezien het een "SELECT" query is zal 't verder geen (blijvende) effecten in je DB hebben "mocht het onverhoopt mis gaan".

[ Voor 28% gewijzigd door RobIII op 09-05-2024 12:24 ]

[Sjoerd_r]

RobIII schreef op donderdag 9 mei 2024 @ 12:23:
[...]

Dat is nergens voor nodig. Er zijn gratis alternatieven die exact dezelfde (basis) functionaliteit hebben.

[...]

...heb ik nog altijd de reservekopie van de executable.

Gezien het een "SELECT" query is zal 't verder geen (blijvende) effecten in je DB hebben "mocht het onverhoopt mis gaan".

Gelukkig haalt het programmatje alleen data uit de database en doet er verder geen aanpassingen aan.

Ik heb de HEX editor gedownload en eens even bekeken, voor mij is het allemaal Chinees wat er staat.

Uiteraard zou ik graag willen leren hoe ik het aanpas voor een eventuele volgende keer, maar voor mij is dit geen dagelijks werk.

[ Voor 0% gewijzigd door Sjoerd_r op 09-05-2024 12:33 . Reden: typo ]

[RobIII]

Sjoerd_r schreef op donderdag 9 mei 2024 @ 12:32:
Ik heb de HEX editor gedownload en eens even bekeken, voor mij is het allemaal Chinees wat er staat.

Het is net als een tekstverwerker, maar dan een binary-editor. Blijf overal van af, zoek de query (CTRL+F "Select" ofzo), overschrijf die, vul aan met spaties (maar NIET langer), save, probeer, profit.

[Sjoerd_r]

Maar hoe kan ik die query vinden, het is één groot bestand zoals hieronder:


Dat waar ik het uit had kon ik tenminste nog begrijpen:

[RobIII]

Kijk eens in het menu bovenaan. Daar staat een Search CTRL+F werkt vast ook. Desnoods gewoon even scrollen. Ik zit even niet achter een PC om alle details te checken, maar je komt er vast met wat doorzetten, googlen of ChatGPT uit.

Edit: https://www.sweetscape.com/010editor/manual/Find.htm
Oh, ik gok dat je wil zoeken op Unicode string.




Dat maakt 't vervangen van die string ook iets lastiger; tussen elk karakter staat een 0-byte (00 in de linker "kolom"). Die wil je wel in tact laten. MIsschien is je beste optie een "(unicode) search met (unicode) replace". Maar dan nog is het belangrijk dat de string lengte identiek blijft en de executable dus op de byte exact even groot. Ik weet even niet of 010 Editor een handige functie heeft om een unicode string te vervangen, maar karakter-voor-karakter aanpassen is ook maar een paar minuten werk en je hoeft 't niet elke week te doen, toch?

Edit 2: Oh, er is een "paste special" -> Unformatted unicode text. There you go. Selecteer de hele query, overschrijf die met een paste-special -> unformatted unicode text. Het *blijft* zaak dat alles NA de string op z'n plek blijft, dus vul waar nodig aan met 0-bytes (of "unicode spaties").

Ik ga even een eind scooteren en een ijsje eten, je komt er vast uit. Het is echt geen rocket science.

[ Voor 140% gewijzigd door RobIII op 09-05-2024 13:36 ]

[Sjoerd_r]

Geniet van je ijsje en dank!
*snip* Sorry, nee. Devschuurder werven? Gebruik Vraag & Aanbod!

[ Voor 98% gewijzigd door RobIII op 09-05-2024 14:51 ]

[RobIII]

Nee, sorry, dat is hier niet de bedoeling. Maar probeer het eerst eens even zelf. Je kunt dit. Trust me.

[ Voor 5% gewijzigd door RobIII op 09-05-2024 14:52 ]

[Voutloos]

Op basis van die changelog kan je absoluut niet het gedrag weten. Dus je moet dit zelf testen: Komt nieuwere/gewijzigde data dus ook alsnog in de old_adres terecht?

Want anders moet je juist zorgen dat je query werkt met de nieuwere structuur.

Nogmaals, je kan het enkel weten door te meten , maar als ik een gok mag doen zou ik verwachten dan je nieuwe data gaat missen, omdat die tabel enkel bestaat voor als je direct een versie terug zou draaien.

[sig69]

vistu schreef op donderdag 9 mei 2024 @ 12:07:
Is t geen optie een view te maken naar de nieuwe tabel met de oude naam? Of gaat dat qua naamgeving mis?

Indien mogelijk zou ik dit proberen.

[The Eagle]

View is verreweg het makkelijkste ja. Gewoon zorgen dat wat het stuk programma vraagt, in een view staat en de juiste kolomnamen bevat.
Create view is een paar regels code en als ie niet goed is drop je de view en bouw je hem opnieuw. Dus niks decompilen of anderszins moeilijk doen

Daarnaast: je leverancier heeft je die update gestuurd. Wat zei die toen je de vraag stelde?
Daarnaast: Weet je zeker dat je niet een table rename script bent vergeten te draaien? En hoe kijkt jullie dba er tegenaan?

* The Eagle 15 jaar in de ERP gezeten en dit zijn redelijk basis dingen, met iedere upgrade vergeten ze wel wat. Dan bel je support en krij je een fix

[RobIII]

vistu schreef op donderdag 9 mei 2024 @ 12:07:
Is t geen optie een view te maken naar de nieuwe tabel met de oude naam? Of gaat dat qua naamgeving mis?

Van wat ik van TS begrijp zijn er 2 kolommen hernoemd; een view maken gaat dan dus niet werken want die conflicteert met de (nog steeds) bestaande tabelnaam en je wil dat de ERP software ook nog gewoon blijft werken naast die (verouderde) tool die TS nu probeert te 'tweaken'.

Wat wél een optie is is een 'hybride': Een view maken (bijv 'vw-012' ipv 'ba-012') en in de executable alleen de tabelnaam te vervangen met de viewnaam. Dan hoef je iig minder te klooien met die string exact even lang te houden ofzo en is de fix dus maar een byte of 2 (of 4 als je van beide tabellen een view maakt).

[ Voor 7% gewijzigd door RobIII op 09-05-2024 18:00 ]

[farlane]

Wellicht moet je rekening houden met het feit dat het PE file format ook in checksums voorziet, en je bestand mogelijk niet meer start als die niet kloppen.

Makkelijkst is om die dude aan z'n veren te trekken of het tooltje zelf/laten namaken als je het mij vraagt.

[RobIII]

farlane schreef op donderdag 9 mei 2024 @ 19:38:
Wellicht moet je rekening houden met het feit dat het PE file format ook in checksums voorziet, en je bestand mogelijk niet meer start als die niet kloppen.

Ik zal het zo even testen, maar tenzij die executable gesigned is moet het volgens mij gewoon werken.

Edit: werkt:


Maar dan ga ik er, nogmaals, even van uit dat de binary niet gesigned is o.i.d.

Makkelijkst is om die dude aan z'n veren te trekken of het tooltje zelf/laten namaken als je het mij vraagt.

Even aangenomen dat het aanpassen van de executable werkt (in dit vrij specifieke, uitzonderlijke geval): dat is een klus van 5 minuten. Zelf (her)bouwen of laten namaken gaat het daar tegen afleggen.

Neemt niet weg dat het over het algemeen beter is óf die knakker zo ver te krijgen, óf de source te zien bemachtigen, óf die ERP toko eens aan te schieten óf... Dat ben ik met iedereen eens hoor. Maar dit is een vrij specifiek geval waar maar een kleine aanpassing in een (plain (weliswaar unicode) text) string minimaal aangepast moet worden.

[ Voor 18% gewijzigd door RobIII op 09-05-2024 20:28 ]

[The Eagle]

@RobIII of een view wel of niet gaat werken ligt aan het dbms en de prio waarin die de objecten selecteert. En anders heb je ook nog zoiets als een alias.

Maar bottom line is hier dat de leverancier een update heeft uitgeleverd waarbij wel de db geupdate is maar ze een stuk code zijn vergeten aan te passen. Dat kun je zelf fixen, maar bij de volgende update ben je weer het bokje. Dus vraag de leverancier om een fix.

Heb er nog even doorheen gelezen, als ik dit op zou moeten lossen zou ik denk ik twee kolommen met de juiste (oude) namen aan de tabel toevoegen, die vullen met de bestaande waarden uit de hernoemde velden en dan een trigger on insert, delete en update maken zodat de nieuwe kolommen ook automatisch bijgehouden worden.

Ranzig, maar het werkt

Maar nogmaals: als je zoiets toepast is het een workaround en ga je bij de eerste update die die tabel of de code wijzigt weer nat.

[RobIII]

The Eagle schreef op donderdag 9 mei 2024 @ 20:29:
Heb er nog even doorheen gelezen, als ik dit op zou moeten lossen zou ik denk ik twee kolommen met de juiste (oude) namen aan de tabel toevoegen, die vullen met de bestaande waarden uit de hernoemde velden en dan een trigger on insert, delete en update maken zodat de nieuwe kolommen ook automatisch bijgehouden worden.

Dan zou ik dus een computed column doen. Of een view. Veel makkelijker, geen triggers etc. Maar ik zou juist zoveel mogelijk van die tabel(len) en DB afblijven, want dat ERP gaat dat geheid (ooit) niet leuk vinden.

The Eagle schreef op donderdag 9 mei 2024 @ 20:29:
Maar nogmaals: als je zoiets toepast is het een workaround en ga je bij de eerste update die die tabel of de code wijzigt weer nat.

Juist. Juist daarom zou ik liever dat tooltje 'tweaken' en van heel dat ERP en diens DB afblijven.

Maar goed, TS heeft inmiddels meer dan voldoende opties

[ Voor 29% gewijzigd door RobIII op 09-05-2024 20:32 ]

[farlane]

The Eagle schreef op donderdag 9 mei 2024 @ 20:29:
@RobIII
Maar bottom line is hier dat de leverancier een update heeft uitgeleverd waarbij wel de db geupdate is maar ze een stuk code zijn vergeten aan te passen.

Nja, dat wat omvalt is een of ander apart tooltje geschreven voor die specifieke klant. Zou zo maar kunnen zijn dat dat niet eens van de leverancier is?

[The Eagle]

RobIII schreef op donderdag 9 mei 2024 @ 20:30:
[...]

Dan zou ik dus een computed column doen. Veel makkelijker, geen triggers etc. Maar ik zou juist zoveel mogelijk van die tabel(len) en DB afblijven, want dat ERP gaat dat geheid (ooit) niet leuk vinden.

Computed column kan ook idd, maar dit is Progress zo te zien (zie driver screenshot in startpost). Geen idee of die dat ondersteunt. Triggers doen ze allemaal

[The Eagle]

farlane schreef op donderdag 9 mei 2024 @ 20:35:
[...]


Nja, dat wat omvalt is een of ander apart tooltje geschreven voor die specifieke klant. Zou zo maar kunnen zijn dat dat niet eens van de leverancier is?

Ah wacht, dat losse tooltje had ik even gemist.
Dan gaat de leverancier van het erop systeem je ook uitzwaaien want eigen custom :W

[farlane]

Ja precies. En bij de volgende update mogelijk weer. /shrug

[RobIII]

The Eagle schreef op donderdag 9 mei 2024 @ 20:41:
Ah wacht, dat losse tooltje had ik even gemist.
Dan gaat de leverancier van het erop systeem je ook uitzwaaien want eigen custom :W

Ja, juist daarom wil je dat (van wat ik begrijp) niet meer onderhouden / ondersteunde 3rd party(!) tooltje aanpassen en niet aan de DB of het ERP komen.

farlane schreef op donderdag 9 mei 2024 @ 20:43:
En bij de volgende update mogelijk weer. /shrug

Ja, dat risico bestaat. Uiteraard.

[ Voor 19% gewijzigd door RobIII op 09-05-2024 21:23 ]

[farlane]

RobIII schreef op donderdag 9 mei 2024 @ 21:21:
[...]

Ja, juist daarom wil je dat (van wat ik begrijp) niet meer onderhouden / ondersteunde 3rd party(!) tooltje aanpassen en niet aan de DB of het ERP komen.

[...]

Ja, dat risico bestaat. Uiteraard.

Nu een korte klap met wat gepruts is prima, begrijp me niet verkeerd. Maar men vergeet dan vaak een oplossing te maken die wel toekomstbestendig is.

[sig69]

farlane schreef op donderdag 9 mei 2024 @ 22:27:
[...]


Nu een korte klap met wat gepruts is prima, begrijp me niet verkeerd. Maar men vergeet dan vaak een oplossing te maken die wel toekomstbestendig is.

Het gepruts heeft jaren prima gewerkt blijkbaar dus is best rendabel geweest. Eens dat direct in de database wroeten niet de beste oplossing is, liefst praat je tegen een api ofzo. Maar ook die veranderen wel eens, en als ze er niet zijn, dan maar zo. Vaak zat meegemaakt. Het werkt nu, garantie tot aan de deur.

[Sjoerd_r]

Ik ben inmiddels ook weer teug van het ijsje eten met vrouw en kinders :-)

Het programmatje is ooit een keer in elkaar geknutseld door een "knakker" welke niet voor het ERP software bedrijf werkt. Deze "knakker" is helaas niet meer te vinden.

Voor de toekomst bestaat er een leuk pakket die alle labels aanmaakt, maar daar maf je het eerste jaar 6k voor betalen en alle opvolgende jaren een fee van 3k. De oplossing die we hadden werkte altijd prima en gratis.... Daarom zonde om voor zo'n tabelwijziging gelijk een duur pakket te kopen terwijl het misschien zelf ook te fixen is, daarnaast zou het implementeren van een andere software pas over 2 maanden kunnen.

Ik ben nu zover ( jaja) dat ik met unicode in 010 editor de locatie van Adres en adresdelen heb gevonden, nu kan ik met replace dit veranderen in old_adres en old_adresdelen, maar dan start het programmatje niet meer

Het programmatje is niet voorzien van een digitale handtekening.

[ Voor 0% gewijzigd door Sjoerd_r op 10-05-2024 09:03 . Reden: typo ]

[sig69]

Exporteren vanuit dotpeek, query aanpassen en nieuwe build maken in visual studio. Misschien ook een optie.

[Merethil]

Sjoerd_r schreef op vrijdag 10 mei 2024 @ 09:02:
Ik ben inmiddels ook weer teug van het ijsje eten met vrouw en kinders :-)

Het programmatje is ooit een keer in elkaar geknutseld door een "knakker" welke niet voor het ERP software bedrijf werkt. Deze "knakker" is helaas niet meer te vinden.

Voor de toekomst bestaat er een leuk pakket die alle labels aanmaakt, maar daar maf je het eerste jaar 6k voor betalen en alle opvolgende jaren een fee van 3k. De oplossing die we hadden werkte altijd prima en gratis.... Daarom zonde om voor zo'n tabelwijziging gelijk een duur pakket te kopen terwijl het misschien zelf ook te fixen is, daarnaast zou het implementeren van een andere software pas over 2 maanden kunnen.

Ik ben nu zover ( jaja) dat ik met unicode in 010 editor de locatie van Adres en adresdelen heb gevonden, nu kan ik met replace dit veranderen in old_adres en old_adresdelen, maar dan start het programmatje niet meer

Het programmatje is niet voorzien van een digitale handtekening.

Heb je er dan ook rekening mee gehouden dat de totale lengte van de hex code niet hoger mag zijn dan voor je wijziging? Gewoon find+replace werkt niet in dit geval want je verschuift daarmee allerhande vervolgcode waardoor je programma nu niet meer weet waar wat staat. Daarom zei RobIII ook dat je de boel moest replacen met een even lang of kortere reeks tekens, en aanvullen met spaties aan het eind van je wijziging tot hij exact even lang is als de huidige code.

[RobIII]

Sjoerd_r schreef op vrijdag 10 mei 2024 @ 09:02:
Ik ben nu zover ( jaja) dat ik met unicode in 010 editor de locatie van Adres en adresdelen heb gevonden, nu kan ik met replace dit veranderen in old_adres en old_adresdelen, maar dan start het programmatje niet meer

Dan wed ik een krat bier dat er dingen 'verschoven' zijn ná de query. Zoals ik steeds blijf benadrukken: je moet dezelfde ruimte die er nu is voor de query zien te benutten; zie mijn allereerste post. Er mag geen byte bij komen, noch af gaan. Alles NA de query moet precies op z'n plek blijven staan. En dus moet je 'plek' maken zoals ik in mijn eerste post heb gedaan door de tabellen te aliassen als 'a' en 'b'.

Merethil schreef op vrijdag 10 mei 2024 @ 10:19:
Heb je er dan ook rekening mee gehouden dat de totale lengte van de hex code niet hoger mag zijn dan voor je wijziging?

En óók niet lager.

[ Voor 14% gewijzigd door RobIII op 10-05-2024 10:21 ]

[Merethil]

RobIII schreef op vrijdag 10 mei 2024 @ 10:20:
[...]

En óók niet lager.

Vandaar mijn verdere uitleg, maar ik had inderdaad moeten toevoegen

(óf lager!)

[Voutloos]

Neuh, jullie hadden het allebei niet zo uitvoerig hoeven te zeggen, want het stond al zeer uitvoerig in de eerste paar berichten.

[Sjoerd_r]

Dank jullie allen voor het meedenken, ik had het zover dat de regels aangepast waren maar nu krijg ik een ander foutmelding.

Foto1 de aanpassing en foto 2 de nieuwe foutmelding. Als ik hier niet uit kom dan geef ik het op.

[RobIII]

Je hebt punten getyped waar nullen horen te staan. Kijk eens in dat linker vlak. Om de byte hoort er 00 te staan (en die worden rechts (ook) weergegeven als punt). Daar heb jij nu échte punten (2E linkervlak) neergezet.

Het linker (brede) vlak zijn de (hexadecimale) waardes van de bytes. Elk groepje van 2 getallen/letters is 1 byte. De rechter (smalle) kolom is de (ASCII) weergave van die bytes. Omdat een heleboel bytes niet corresponderen met een leesteken (zoals een 0-byte of, zeg, een 'backspace' of 'tab') worden alle niet-representeerbare tekens met een punt weergegeven.

Als je de query aan wil passen moet je dus <leesteken> <0-byte> <leesteken> <0-byte> <leesteken> <0-byte> ... hebben in het linker vlak. ^{Waarbij "leesteken" de ASCII code van de letter is.} Ik zie waar jij de aanpassingen hebt gemaakt <leesteken> <2E> <leesteken> <2E> <leesteken> <2E> ... en 2E is de hexadecimale waarde voor een punt. Dat moeten dus 0-bytes zijn.

Het is misschien even vallen en opstaan, dat besef ik, maar het is écht niet moeilijk.



Ze springen er als een zwerende vinger uit omdat de rest van die kolom (voor zover die querystring betreft) alleen maar nullen bevat. Verder heb je niet de query helemaal aangepast zoals ik in mijn eerste post aangaf. Het is wel zaak dat je instructies precies opvolgt

[ Voor 91% gewijzigd door RobIII op 10-05-2024 13:16 ]

[Sjoerd_r]

Het linker (brede) vlak zijn de (hexadecimale) waardes van de bytes. Elk groepje van 2 getallen/letters is 1 byte. De rechter (smalle) kolom is de (ASCII) weergave van die bytes. Omdat een heleboel bytes niet corresponderen met een leesteken (zoals een 0-byte of, zeg, een 'backspace' of 'tab') worden alle niet-representeerbare tekens met een punt weergegeven.

Ik begin het steeds een beetje meer te snappen, geloof ik...

Maar van die 03 mag ik geen 00 maken denk ik?

Net wat je zei, er is een beetje ruimtegebrek om die old_ ervoor te zetten

[RobIII]

Sjoerd_r schreef op vrijdag 10 mei 2024 @ 20:25:
Maar van die 03 mag ik geen 00 maken denk ik?

Nee.

Sjoerd_r schreef op vrijdag 10 mei 2024 @ 20:25:
Net wat je zei, er is een beetje ruimtegebrek om die old_ ervoor te zetten

Ik weet niet wat je nu aan 't aanpassen bent, maar dat is niet nodig. Er is geen ruimtegebrek, je hebt zelfs ruimte over als je gewoon de query gebruikt die ik, wederom, in mijn eerste post gaf. Die is korter dan de huidige query. En die query aliased veldnamen naar namen zoals de executable ze verwacht dus je hoeft verder - 99.999% zeker - niets aan te passen dan die query.

[ Voor 22% gewijzigd door RobIII op 10-05-2024 20:32 ]

[Sjoerd_r]

Ik weet niet wat je nu aan 't aanpassen bent, maar dat is niet nodig. Er is geen ruimtegebrek, je hebt zelfs ruimte over als je gewoon de query gebruikt die ik, wederom, in mijn eerste post gaf. Die is korter dan de huidige query. En die query aliased veldnamen naar namen zoals de executable ze verwacht dus je hoeft verder - 99.999% zeker - niets aan te passen dan die query.

Excuses, weekend zat ertussen

Nadat ik het had aangepast krijg ik de foutcode "kan ADRESDELEN niet in de kolom vinden" verderop in de code staat er nog een regel "ADRESDELEN" welke dus waarschijnlijk ook aangepast moet worden in "OLD_ADRESDELEN" dat is wat ik nu probeer aan te passen. allen daar is bijna geen ruimte, zie screenshot:


Kan ik de hele code opschuiven totdat ik in die spaties uitkom en wel genoeg ruimte heb?

[Blasterxp]

klinkt misschien gek,
maar zou je op de database omgeving niet een view kunnen maken?
zo kan de query weer praten met de database, en zorgt de view dat er een 'tablet' met juiste naam, en juiste kolommen bestaat.

[Sjoerd_r]

Blasterxp schreef op maandag 13 mei 2024 @ 11:37:
klinkt misschien gek,
maar zou je op de database omgeving niet een view kunnen maken?
zo kan de query weer praten met de database, en zorgt de view dat er een 'tablet' met juiste naam, en juiste kolommen bestaat.

Geen idee of het gek klink, maar zoals aangegeven ben ik geen held met databases, dus hoe doe ik dat?

[RobIII]

Sjoerd_r schreef op maandag 13 mei 2024 @ 11:25:
Nadat ik het had aangepast krijg ik de foutcode "kan ADRESDELEN niet in de kolom vinden" verderop in de code staat er nog een regel "ADRESDELEN" welke dus waarschijnlijk ook aangepast moet worden in "OLD_ADRESDELEN" dat is wat ik nu probeer aan te passen. allen daar is bijna geen ruimte, zie screenshot:
[Afbeelding]

Zoals ik al zei: Waarom ben je dat in hemelsnaam aan 't aanpassen? Je moet alléén de (héle) query in die applicatie aanpassen; de query zorgt ervoor dat de oude veldnamen gewoon gebruikt kunnen (blijven) worden (omdat er aliasses gebruikt worden: SELECT a.oldadres as adres, a.oldadresdelen as adresdelen, ... etc.)

Sjoerd_r schreef op maandag 13 mei 2024 @ 11:25:
Kan ik de hele code opschuiven totdat ik in die spaties uitkom en wel genoeg ruimte heb?

Nee. Dat is nu onderhand al 15 keer gezegd. Het is zaak dat alles 'buiten" de querystring op exact dezelfde plek blijft staan.

Blasterxp schreef op maandag 13 mei 2024 @ 11:37:
klinkt misschien gek,
maar zou je op de database omgeving niet een view kunnen maken?
zo kan de query weer praten met de database, en zorgt de view dat er een 'tablet' met juiste naam, en juiste kolommen bestaat.

Hoe wou je dat doen zonder de software aan te passen om die view te gebruiken? Is wel minder wijziging (in bytes zeg maar) en bij eventuele latere breaking changes kun je de view aanpassen waar nodig zonder (weer) aan die software te moeten komen. Je idee is verder dus zeker niet slecht, maar wel ook al eerder aangekaart in dit topic

Sjoerd_r schreef op maandag 13 mei 2024 @ 11:38:
Geen idee of het gek klink, maar zoals aangegeven ben ik geen held met databases, dus hoe doe ik dat?

We kunnen en willen je best in de juiste richting sturen, maar een klein beetje eigen inzet verwachten we hier wel. Google eens "How to create a view" met eventueel een RDBMS naam erachter voor het specifieke SQL dialect. Kom je er niet uit dan kun je hier je query posten en kunnen we kijken wat we voor je kunnen betekenen. Maar let wel: alle instructies tot-nu-toe (die je tot nu toe niet héél erg goed opvolgt) zijn dan niet meer relevant.

[ Voor 73% gewijzigd door RobIII op 13-05-2024 13:53 ]

[Sjoerd_r]

RobIII schreef op maandag 13 mei 2024 @ 13:06:
[...]

Zoals ik al zei: Waarom ben je dat in hemelsnaam aan 't aanpassen? Je moet alléén de (héle) query in die applicatie aanpassen; de query zorgt ervoor dat de oude veldnamen gewoon gebruikt kunnen (blijven) worden (omdat er aliasses gebruikt worden: SELECT a.oldadres as adres, a.oldadresdelen as adresdelen, ... etc.)


[...]

Nee. Dat is nu onderhand al 15 keer gezegd. Het is zaak dat alles 'buiten" de querystring op exact dezelfde plek blijft staan.

Mijn excuses, ben schoon begonnen en heb het aangepast zoals je hebt voorgesteld in je eerste post, zie screenshot:


Daar komt een foutmelding uit die ik nog niet eerder heb gezien:


Geloof me, ik google me al suf

[RobIII]

Ja, sorry, ik zie nu dat ik \" heb overgenomen uit jouw post, maar ik realiseer me nu dat die backslashes natuurlijk escape sequences zijn voor de query die jij in Jetbrains zag in C# strings. Alle \" moeten 'gewoon' " worden. (dus de backslashes voor quotes weg). Dat is my bad, excuus. Ik heb mijn eerste post daar op aangepast. Verder (maar ik ben geen computer ) ziet de wijziging in je screenshot er, op 't oog in ieder geval, goed uit.

[ Voor 44% gewijzigd door RobIII op 13-05-2024 15:05 ]

[Haan]

Het goede nieuws is dus dat het aanpassen van de query inmiddels gelukt is
Maar je hebt dus ergens nog een foutje zitten in de query zelf, bijvoorbeeld een spatie vergeten ofzo, dus even goed kijken naar wat je nu in je code hebt staan.
Opmerking waarschijnlijk overbodig, laatste reactie niet gezien

[ Voor 12% gewijzigd door Haan op 13-05-2024 18:06 ]

[Sjoerd_r]

De foutmelding is eruit!

Alleen worden er nu geen adres gegevens opgehaald, wel de naam van de klant en de bestelde producten.

Maar dat we nu geen foutcode meer hebben is een grote sprong voorwaarts.

Mijn dank is groot!

Maar vooraleer ik dit allemaal snap.....

[RobIII]

Sjoerd_r schreef op dinsdag 14 mei 2024 @ 09:24:
Alleen worden er nu geen adres gegevens opgehaald

En die staan wel in dat oldadres of oldadresdelen veld?

Sjoerd_r schreef op dinsdag 14 mei 2024 @ 09:24:
Maar vooraleer ik dit allemaal snap.....

Naja, het was al een beetje te merken natuurlijk, maar je zit in Softwareontwikkeling. Je kunt niet verwachten dat, als je geen ervaring hebt op dat vlak, alles snapt op basis van zo'n topic. Daar komt wel wat meer bij kijken.

[Sjoerd_r]

RobIII schreef op dinsdag 14 mei 2024 @ 09:35:
[...]

En die staan wel in dat oldadres of oldadresdelen veld?


[...]

Naja, het was al een beetje te merken natuurlijk, maar je zit in Softwareontwikkeling. Je kunt niet verwachten dat, als je geen ervaring hebt op dat vlak, alles snapt op basis van zo'n topic. Daar komt wel wat meer bij kijken.

Volgens de tabel zouden ze erin moeten staan.

[RobIII]

Sjoerd_r schreef op dinsdag 14 mei 2024 @ 09:57:
Volgens de tabel zouden ze erin moeten staan.

Er kan vanalles in de documentatie staan, wat is de praktijk? Heb je al eens gekeken in de tabel?

[Voutloos]

Voutloos schreef op donderdag 9 mei 2024 @ 14:54:
Op basis van die changelog kan je absoluut niet het gedrag weten. Dus je moet dit zelf testen: Komt nieuwere/gewijzigde data dus ook alsnog in de old_adres terecht?

Want anders moet je juist zorgen dat je query werkt met de nieuwere structuur.

Nogmaals, je kan het enkel weten door te meten , maar als ik een gok mag doen zou ik verwachten dan je nieuwe data gaat missen, omdat die tabel enkel bestaat voor als je direct een versie terug zou draaien.

1 op 1 kopie van iets dat je niet goed gelezen hebt.
Met zelf testen bedoel ik dus ‘voeg nieuwe data toe en doe een query.’
De query kan ook buiten je tool om, dus dit onderzoekje had je al kunnen doen voor het hex edit avontuur.

[PiHole]

Ik gebruik de ODBC connector van wholesale dagelijks en begrijp de pijn in deze.
Zelf meerdere malen oude .exe moeten updaten omdat links of rechtsom het niet meer werkte.

Dit deed ik met eergenoemde dnSpy.
Kwestie van de exe erin slepen, als het goed is kan die wel gedecompiled worden.
Dan kan je die aanpassen en recompilen. *snip* Goedbedoeld, maar niet de bedoeling hier

maar wat betreft de labels maken, waarom niet de standaard gebruiken die ingebakken is in wholesale?
Er is een gehele Transsmart koppeling die in te richten is. Krijg je automatisch alle labels zodra je de magazijnbon afmeld.

En die staan wel in dat oldadres of oldadresdelen veld?

Kan zijn dat het herstel programma gedraait moet worden en daarom leeg is, dat haal ik niet uit bovenstaande screen.

[ Voor 6% gewijzigd door RobIII op 14-05-2024 16:47 ]

[Sjoerd_r]

maar wat betreft de labels maken, waarom niet de standaard gebruiken die ingebakken is in wholesale?
Er is een gehele Transsmart koppeling die in te richten is. Krijg je automatisch alle labels zodra je de magazijnbon afmeld.

De tool die we hebben/hadden was gratis en Transsmart kost een paar K per jaar en de implementatie zou pas over een paar maand kunnen.

Zoals gezegd, ik heb geen it en of software kennis, ben enkel de gebruiker en manus van alles die het probleem probeert op te lossen

Maar wel fijn dat nog iemand de pijn kent van Wholesale

[mbe81]

PiHole schreef op dinsdag 14 mei 2024 @ 16:34:
[Afbeelding]

[...]


Kan zijn dat het herstel programma gedraait moet worden en daarom leeg is, dat haal ik niet uit bovenstaande screen.

Als ik de tekst lees, dan lees ik dat de velden zijn komen te vervallen en de old_adres velden alleen nog maar aanwezig zijn om adressen op te slaan die niet geconverteerd konden worden.

Ik vermoed dat de er een nieuwe tabel is gemaakt waarin de adressen voortaan worden opgeslagen en dat je dus een compleet andere query nodig hebt om de data er uit te halen.

[Sjoerd_r]

Dank allemaal voor jullie input, daar het toch lijkt dat er een nieuwe tabel is aangemaakt gaat deze oplossing niet werken.

Mag mag wel een slotje op het topic.

[mbe81]

Het kan nog steeds wel gaan werken. Je zal een nieuwe query moeten maken die dezelfde kolommen oplevert, al dan niet middels aliassen.
Als je een tool hebt om de database te benaderen, tabellen te inspecteren en een query te schrijven is dit goed te doen.
Daarna kan je deze query op bovenstaande manier terugplaatsen in je executable.

[PiHole]

code:

DataTable dataTable5 = new DataTable("adres");
new OdbcDataAdapter(string.Format("SELECT ba012.plaats, ba012.postcode, ba012.straat, ba012.huisnr, ba011.cdiso AS CDLAND, ba011.naamlandint, ba012.cdadsdef FROM PUB.\"ba-012\" ba012 LEFT OUTER JOIN PUB.\"ba-011\" ba011 ON ba011.cdland = ba012.cdland WHERE ba012.\"id-cdads\" = '{0}'", RuntimeHelpers.GetObjectValue(dataRow["CDADRES"])), mdlAlgemeen.odbcMultivers).Fill(dataTable5);


    if (dataTable5.Rows.Count >= 1)
{
    DataRow row = dataTable5.Rows[0];
    this._Straat = Conversions.ToString(row["straat"]);
    this._Huisnr = Conversions.ToString(row["huisnr"]);
    this._Postcode = Conversions.ToString(row["postcode"]);
    this._Plaats = Conversions.ToString(row["plaats"]);
    this._HnrToev = null;
}

het zal zoiets moeten worden.
De adresdelen zijn nu niet meer in 1 kolom maar over meerdere kolommen verdeeld in de database.
Daarom kan je de code versimpelen naar bovenstaand.
huisnummer toevoeging splitsen is eigenlijk overbodig, de meeste huizen hebben geen toevoeging en labels werken prima als er huisnummer 1a staat.

[Voutloos]

Sjoerd_r schreef op woensdag 15 mei 2024 @ 08:50:
Dank allemaal voor jullie input, daar het toch lijkt dat er een nieuwe tabel is aangemaakt gaat deze oplossing niet werken.

Mag mag wel een slotje op het topic.

Er was al meermaals gezegd om ook zelf een query te testen met nieuwe data. Dus als dat te lastig is, houdt het qua software ontwikkeling ook wel op.