azcomputerguru/claudetools
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
30933bd35df97c3096d17388ab110ee318f97694
claudetools/wiki/projects/valleywide-orders-modernization.md
Mike Swanson 4fd5688026 sync: auto-sync from Mikes-MacBook-Air.local at 2026-06-14 08:36:19 
Author: Mike Swanson
Machine: Mikes-MacBook-Air.local
Timestamp: 2026-06-14 08:36:19
2026-06-14 08:36:21 -07:00

14 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 Mikes-MacBook-Air/claude-main
clients/valleywide/app-modernization/CONTEXT.md
clients/valleywide/app-modernization/source-code/Orders-VWP_Current-2020/
clients/valleywide/app-modernization/docs/MODERNIZATION_ROADMAP.md
clients/valleywide/session-logs/2026-06/2026-06-13-mike-vwp-server3-migration-and-orders-source-recovery.md
clients/valleywide/session-logs/2026-06/2026-06-14-mike-orders-modernization-roadmap.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.

Modernization Roadmap (2026-06-14)

A comprehensive 7-phase roadmap has been established for migrating ORDERS from VB6/Jet to a modern web application. The strategy uses a dual-client architecture (strangler pattern) where both VB6 and web clients share the same SQL Server backend during development, enabling gradual module-by-module migration with real-user beta testing.

Full roadmap: clients/valleywide/app-modernization/docs/MODERNIZATION_ROADMAP.md

Core Strategy

  1. Jet → SQL Server migration first (Month 1) — Removes 2GB limit and Win7 VM dependency. VB6 modADO.bas updated for SQL Server connection strings.
  2. Dual-client architecture (Months 2-9) — VB6 and web client coexist, both accessing SQL Server. Enables live-beta platform with 3-5 real users testing web modules while production continues on VB6.
  3. Module-by-module rollout — Read-only modules first (project lists, reports), then light data entry, then complex modules, with certified payroll and positive pay last (compliance-critical).
  4. Single cutover to SQL storage — No migrate-twice. Once SQL Server is live, both clients use it. Web client gradually replaces VB6 modules until full cutover.

Timeline (8-9 Months)

Phase Duration Focus Key Deliverables
1: Foundation & Database Month 1 Jet→SQL migration, modADO update SQL Server live, VB6 on SQL verified
2: Web Foundation & API Month 2 REST API, auth framework API layer operational, auth working
3: Read-Only Modules Months 2-3 Project lists, reports, view-only forms 3-5 beta users testing read access
4: Light Data Entry Months 3-4 Simple CRUD forms (inventory, contacts) Beta users entering new data via web
5: Complex Modules Months 5-6 Takeoffs, change orders, job costing Core business logic migrated
6: Compliance Modules Months 7-8 Certified payroll, positive pay (3 banks) Legal requirements met in web client
7: Full Rollout Months 8-9 Remaining modules, training, cutover All users on web client, VB6 retired

Technical Safeguards

  • Row versioning — SQL Server optimistic concurrency prevents VB6/web conflicts
  • Feature flags — Per-module rollback capability if web version has issues
  • Audit logging — Track which client type (VB6/web) performed each operation
  • Blazor Server/.NET 8 recommended — Strong data binding for complex forms, .NET ecosystem alignment

Risk Mitigation

  • Crystal Reports — 791 reports preserved initially via Crystal for .NET runtime; gradual re-platforming to modern reporting engine (SSRS/DevExpress) in Phase 7
  • OCX grid logic — Business rules in True DBGrid/FarPoint event handlers migrated to API layer validation + web UI bindings
  • Beta user feedback loop — Each module tested by 3-5 users before general rollout
  • Parallel operation — VB6 remains production-ready throughout; web rollout is additive, not replacement, until Phase 7

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.
2026-06-14 Modernization roadmap established. 7-phase dual-client strategy (8-9 months): Jet→SQL migration first, then gradual web development with strangler pattern. Syncro ticket updated with source recovery announcement.

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