azcomputerguru/claudetools
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
46b5edfba1414b42af419334a95fc7133d48b6e5
claudetools/wiki/projects/valleywide-orders-modernization.md
Mike Swanson 956a39b631 sync: auto-sync from GURU-5070 at 2026-06-14 05:40:26 
Author: Mike Swanson
Machine: GURU-5070
Timestamp: 2026-06-14 05:40:26
2026-06-14 05:40:44 -07:00

10 KiB
Raw Blame History

type, name, display_name, client, status, last_compiled, compiled_by, sources, backlinks
type name display_name client status last_compiled compiled_by sources backlinks
project valleywide-orders-modernization Valley Wide "Orders" App Modernization valleywide active 2026-06-14 GURU-5070/claude-main
clients/valleywide/app-modernization/CONTEXT.md
clients/valleywide/app-modernization/source-code/Orders-VWP_Current-2020/
clients/valleywide/session-logs/2026-06/2026-06-13-mike-vwp-server3-migration-and-orders-source-recovery.md
wiki/clients/valleywide.md
clients/valleywide

Valley Wide "Orders" App Modernization

Assessment + modernization of Valley Wide Plastering's custom construction ERP, an in-house VB6 application called ORDERS (Orders_10A.exe / ORDERS.exe). The original developer ("Darv") is deceased. The app still runs production but is on a dead stack (VB6 + Jet/Access) and is approaching the 2 GB Jet file-size wall. ACG engaged to assess feasibility and a path forward.

Tracking ticket: Syncro #32280 — Source Code Data Recovery (id 110305931).

STATUS HEADLINE (2026-06-13): SOURCE FULLY RECOVERED

The complete VB6 source was believed lost (only frmPayroll.frm had ever been found). On 2026-06-13 it was recovered in full from Darv's machine backup (F:\Darv\Darv.rar, 51 GB, on WINFileSvr 192.168.0.35, extracted to F:\Darv\Darv-rar). The full ORDERS project tree is present with multiple versions; newest …\Kingston\Project\VWP_Current\ORDERS_C.vbp (2020-06-09).

12.2 MB of pure source is staged in the repo at clients/valleywide/app-modernization/source-code/Orders-VWP_Current-2020/ (147 .frm, 4 .bas, 5 .vbp, 2 .Dsr). VB Decompiler Pro is no longer needed — modernization can proceed from real, buildable 2020 source.

The Application

ORDERS is a full construction ERP for a plastering/stucco subcontractor. The ORDERS_C.vbp project links ~40 active forms (the folder holds 128 .frm total, many being Darv's old/bak/xx working copies). Form names map cleanly onto the documented Jet schema (tbl… in clients/valleywide):

Domain Forms (representative) DB tables
Projects & Lots frmProject, frmLotInfo, frmPlans, frmLotOrders, frmChange, frmLotChLog tblPROJECT, tblLOTINFO, tblPLANS, tblCHANGE
Orders & Takeoffs frmOrders, frmTake, frmViewTake, frmInvTake, frmOrderDates tblORDERS, tblTAKE, tblMEASURE
Crew / Labor / Payroll frmCrew(s), frmEmployee, frmLabor, frmPayroll, frmPayHead, frmPaySheet, frmHourList tblCREW, tblHRDAILY, tblPAYHEADER, tblPAYROLL
Certified Payroll frmCertified tblCERTIFIED (prevailing-wage, legal HARD requirement)
Scaffold frmScaffold, frmScafList, frmScafPay, frmSCrew tblScaffold, tblSC_Crew
Inventory / Purchasing frmInventory, frmInvPrice, frmYardOrder, frmPO, frmPOList, frmPOMatrl, frmSupplier, frmContractor tblINVTRY, tblINVPRICE, tblSUPPLIER, tblPOrder, tblYardOrder
AR / AP / Billing / Job Cost frmAR(Master), frmAP(Master), frmBilling, frmMANBILL, frmJCList, frmJCPrint tblARMASTER, tblAPMASTER, tblJOBCOST
Positive Pay (3 banks) frmPosPayC, frmPosPayS, frmPosPayV tblPosPayCRD, tblPosPaySWI, tblPosPayVWP (bank fraud-prevention, HARD dependency)
Repairs frmRepair, frmRepairLot, frmRepList tblREPAIR, tblRepList
Materials/Finishes frmTexture, frmFoam, frmSand, frmBlackPaper —
System frmLogin, frmUser, frmMain, frmSplash, frmAbout, frmError, frmReport tblSECURITY, tblSYSInfo

Technology Stack (confirmed from ORDERS_C.vbp references)

  • Language/runtime: Visual Basic 6.0, compiled P-Code (best case for any fallback decompile — ~70-80% recoverable — but moot now that we have source).
  • Data access: ADO 2.6 (msado26), MS ADO Data Control (MSADODC.OCX), RDO 2.0 (msrdo20), ADOX DDL (msadox) → MS Jet / Access .mdb (Jet 3.x, Access 97 format).
  • Reporting: Crystal Reports 7 ActiveX runtime (craxdrt.dll, Crystl32.OCX) + MS Data Report 6.0 (MSDBRPTR, DataReport1.Dsr, CrystalReport2.Dsr). (~791 .rpt files documented.)
  • Grids: True DBGrid Pro 7.0 (todg7.ocx, tdbg7da) + MS FlexGrid.
  • Spreadsheet grid: FarPoint Spread (Flp32a30.ocx).
  • UI controls: TABCTL32 (tab control), MSCOMCTL / mscomct2 (common controls), comdlg32, EasyP.ocx (EasyPrint).
  • Misc: MSXML 4.0, Scripting Runtime, MS Data Binding (MSBIND), data formatting (msstdfmt).

Data layer is centralized in ADO.bas / ADO2.bas (the modADO module) — the place to start when reading the code.

Database

  • Custom Jet/Access ERP, ~130 tables. Production DB VWP.mdb was 938 MB (2026) and growing (671 MB 2020 → 761 MB 2022 → 938 MB 2026) — approaching the 2 GB Jet hard limit (the core modernization driver). Multiple .mdb copies exist in the Darv backup (e.g. …\000_ASource\Vwp.mdb 801 MB, …\VWP\db1.mdb 120 MB) — left on the server, not in the repo.
  • Modern ACE/DAO drivers refuse to open the Jet 3.x file; earlier schema extraction was via binary scan. With source in hand, the schema can now be read directly from the forms' SQL + modADO.

Modernization Assessment

Constraints that shape every option

  • Certified payroll (prevailing-wage gov't jobs) — legal compliance, cannot be dropped.
  • Positive Pay to 3 banks (CRD/SWI/VWP) — fraud-prevention integration, hard dependency.
  • ~791 Crystal Reports — a large, separate reporting surface to carry or replace.
  • Heavy commercial OCX dependency (True DBGrid, FarPoint Spread, Crystal) — these, not the VB6 language, are the migration's hard part. Lesson from the field: business rules hide in grid event handlers — favor migration that preserves logic over a clean-room rewrite.

Strategy options (industry-standard for VB6 + Jet)

  1. Automated migration to .NET (C#/VB.NET) — baseline-convert with VBUC (Mobilize.Net / gapvelocity "VB6 AI Migrator"; targets up to .NET 8, multi-project), then manual refactor. Preserves ~25 yrs of business logic. Recommended baseline.
  2. Incremental / strangler — expose VB6 via COM/services, rewrite module-by-module; old+new coexist. Lowest risk, longest timeline.
  3. Full rewrite (web/.NET) — only justified if the code is unsalvageable; discards the logic investment and risks the "47 undocumented rules" trap.
  4. Hybrid — keep stable parts on VB6, rewrite the high-value/at-risk parts (data layer + the Jet→SQL move first).

The OCX/report dependencies have direct .NET successors (key finding)

The three commercial controls map cleanly onto modern equivalents from the same vendor lineage (MESCIUS / GrapeCity / ComponentOne — formerly FarPoint), which de-risks the migration:

  • True DBGrid Pro 7 → ComponentOne/MESCIUS FlexGrid (recommended .NET successor; True DBGrid Pro 8 also exists with a migration utility).
  • FarPoint Spread (ActiveX) → Spread for WinForms (.NET) — convert .ss2 designs to XML via the GrapeCity Spread designer; same vendor.
  • Crystal Reports 7 → Crystal Reports for Visual Studio — auto-converts older projects on open (or re-platform reports to a modern engine long-term).
  • Jet/Access .mdb → SQL Server — removes the 2 GB wall, adds proper concurrency/security; data-access already abstracted in modADO, easing the swap.

Suggested first concrete steps

  1. Stand up a VB6 IDE build environment (VB6 SP6 + the OCX set: TABCTL32, todg7, Flp32a30, Crystl32/craxdrt, MSCOMCTL, EasyP) and confirm ORDERS_C.vbp compiles from the recovered tree.
  2. Migrate Jet → SQL Server behind modADO first (biggest pain, lowest UI risk).
  3. Pilot a VBUC conversion of one self-contained module to gauge effort + control-replacement cost.
  4. Inventory the 791 .rpt against what's actually used before committing to a reporting path.

Source Code Status & Locations

  • Recovered tree (repo): clients/valleywide/app-modernization/source-code/Orders-VWP_Current-2020/ (newest ORDERS_C.vbp 2020-06-09; also ORDERS_Cx, historical ORDERSold.vbp 2002 / ORDERSSave). Plus 000_ASource/TEST_VWP.vbp (a LotInfo test harness) and the darv-G-finds/ binaries (ORDERS0727-2015.exe, ORDERS-2005.exe, Package1508 installer + the OCX set).
  • Source of record (server): WINFileSvr 192.168.0.35 — F:\Darv\Darv.rar (51 GB archive) and F:\Darv\Darv-rar (135 GB extract). Also present: VWP_Inv (inventory) and VWP_Update projects (not yet staged). Keep until the source is verified to compile, then the 135 GB extract can be cleaned up.
  • Compiled production build is Orders_10A.exe; the running app is launched via shortcuts to it.

History

Date Event
2026-04-27 App-mod project initiated. VB6 P-Code + Jet 3.x stack confirmed; ~130 tables extracted via binary scan; Crystal 8.5 / 791 .rpt documented. Decompilation planned.
2026-05-14 Ticket #32280 "Source Code Data Recovery" opened.
2026-05-16 VB6 source search across server drives (D/drive2/drive3 scans) — substantial VB6 found, confirming which is VWP's was in progress.
2026-06-13 Full source recovered from Darv.rar (WINFileSvr). Staged to repo; decompilation retired. Found during the SERVER3→VWP-FILES G: migration server sweep.

Reference

  • Ticket: #32280 (id 110305931), customer 31694734.
  • Repo: clients/valleywide/app-modernization/ (CONTEXT.md, source-code/, source-analysis/).
  • Newest project: ORDERS_C.vbp 2020-06-09 — Type=Exe, 80 forms + modADO, 10 OCX/13 references.
  • Related: clients/valleywide (client + the 2026-06-13 G: migration to VWP-FILES).

Modernization research sources

Reference in New Issue View Git Blame Copy Permalink