Sage 100

This should be highlighted with the Sage dev team so they would certainly have time for planning / building a replacement technology for UDS.

When is the next scheduled dev roundtable / webinar?

Might be time to be looking into retirement.....

This should be highlighted with the Sage dev team so they would certainly have time for planning / building a replacement technology for UDS.

When is the next scheduled dev roundtable / webinar?

Some months ago, I read an article that recommended moving away from VBScript. For processes that are outside of the Sage 100, but connect to Sage 100 data,  I've been using PowerShell for the past year. It is more capable than VBScript and takes fewer lines of code to do something. Currently. to run PowerShell scripts they must be launched with the PowerShell interpreter. It would be a major investment by Sage to provide PowerShell scripting within Sage 100. As Microsoft hasn't announced a hard stop on VBScript, there might be three to four years to implement something within Sage 100 for UDS. That is a very short time for Sage 100. The product planners at Sage might also see this as an opportunity to move customers who need UDS to other accounting platforms. The capability of UDS and been a great benefit for customers using Sage 100 to tailor it to their needs. Without UDS in Sage 100, I would think many would seek something else. 

I am not a programmer ( at all ) and I'm purely speculating ( possibly wrongly ) - by the time VBScript is fully EOL  you will have the capability to run the scripting code through AI and have it mostly converted correctly.  Also, the pace of upgrades for Sage 100 is so slow and people can mostly delay upgrading Windows workstations to the point that even if this were announced effective by the end of the year I bet many sites could last another 5-8 years.

Some months ago, I read an article that recommended moving away from VBScript. For processes that are outside of the Sage 100, but connect to Sage 100 data,  I've been using PowerShell for the past year. It is more capable than VBScript and takes fewer lines of code to do something. Currently. to run PowerShell scripts they must be launched with the PowerShell interpreter. It would be a major investment by Sage to provide PowerShell scripting within Sage 100. As Microsoft hasn't announced a hard stop on VBScript, there might be three to four years to implement something within Sage 100 for UDS. That is a very short time for Sage 100. The product planners at Sage might also see this as an opportunity to move customers who need UDS to other accounting platforms. The capability of UDS and been a great benefit for customers using Sage 100 to tailor it to their needs. Without UDS in Sage 100, I would think many would seek something else. 

@Myron Stevenson - How about 90M webinar on how you are using PowerShell (vs VBScript) and how it has benefited your coding?

I am not a programmer ( at all ) and I'm purely speculating ( possibly wrongly ) - by the time VBScript is fully EOL  you will have the capability to run the scripting code through AI and have it mostly converted correctly.  Also, the pace of upgrades for Sage 100 is so slow and people can mostly delay upgrading Windows workstations to the point that even if this were announced effective by the end of the year I bet many sites could last another 5-8 years.

Some months ago, I read an article that recommended moving away from VBScript. For processes that are outside of the Sage 100, but connect to Sage 100 data,  I've been using PowerShell for the past year. It is more capable than VBScript and takes fewer lines of code to do something. Currently. to run PowerShell scripts they must be launched with the PowerShell interpreter. It would be a major investment by Sage to provide PowerShell scripting within Sage 100. As Microsoft hasn't announced a hard stop on VBScript, there might be three to four years to implement something within Sage 100 for UDS. That is a very short time for Sage 100. The product planners at Sage might also see this as an opportunity to move customers who need UDS to other accounting platforms. The capability of UDS and been a great benefit for customers using Sage 100 to tailor it to their needs. Without UDS in Sage 100, I would think many would seek something else. 

I could also help with this, I've been using PowerShell as a replacement for BOI scripts and V/I for years.

@Myron Stevenson - How about 90M webinar on how you are using PowerShell (vs VBScript) and how it has benefited your coding?

I am not a programmer ( at all ) and I'm purely speculating ( possibly wrongly ) - by the time VBScript is fully EOL  you will have the capability to run the scripting code through AI and have it mostly converted correctly.  Also, the pace of upgrades for Sage 100 is so slow and people can mostly delay upgrading Windows workstations to the point that even if this were announced effective by the end of the year I bet many sites could last another 5-8 years.

Some months ago, I read an article that recommended moving away from VBScript. For processes that are outside of the Sage 100, but connect to Sage 100 data,  I've been using PowerShell for the past year. It is more capable than VBScript and takes fewer lines of code to do something. Currently. to run PowerShell scripts they must be launched with the PowerShell interpreter. It would be a major investment by Sage to provide PowerShell scripting within Sage 100. As Microsoft hasn't announced a hard stop on VBScript, there might be three to four years to implement something within Sage 100 for UDS. That is a very short time for Sage 100. The product planners at Sage might also see this as an opportunity to move customers who need UDS to other accounting platforms. The capability of UDS and been a great benefit for customers using Sage 100 to tailor it to their needs. Without UDS in Sage 100, I would think many would seek something else. 

A webinar or breakout session at 90Minds could be helpful. There is a wealth of information available on the web that can help anyone effectively use PowerShell. For example, Doug Finke wrote a module for PowerShell that enables various tasks with an Excel file. Excel doesn't even need to be installed.

Below is a small PowerShell Program that extracts data from CI_Item and puts each record type on a separate worksheet within an Excel workbook. Doing this in VBScript typically requires installing Excel and involves additional lines of VBScript code. PowerShell is very efficient for coding.

Import-Module -Name ImportExcel
$Sage100ExportPath = "C:\Powershell\CI_Item.xlsx"
$Sage100ExportPath
Remove-Item $Sage100ExportPath -ErrorAction Ignore
$conn = New-Object System.Data.Odbc.OdbcConnection
$conn.ConnectionString = "Driver={MAS 90 4.0 ODBC Driver}; UID=MGS; PWD=XXXXXXXX; Company=ABC; Directory=C:\90\V2022\MAS90; Prefix=C:\90\V2022\MAS90\SY\, C:\90\V2022\MAS90\MAS90\==\; ViewDLL=C:\90\V2022\MAS90\MAS90\HOME; LogFile=\PVXODBC.LOG; CacheSize=4; DirtyReads=1; BurstMode=1; StripTrailingSpaces=1; SILENT=1; SERVER=NotTheServer"
$conn.Open()
$dataTable = New-Object System.Data.DataTable                           
$cmd = $conn.CreateCommand()                                            
foreach ($i in 1..5) {                                   
    $cmd.CommandText = "SELECT * FROM CI_Item WHERE ItemType = '$i'"    
    $dataAdapter = New-Object System.Data.Odbc.OdbcDataAdapter $cmd     
    $dataAdapter.Fill($dataTable) | Out-Null                            
    Export-Excel -Path $Sage100ExportPath -InputObject $dataTable -WorksheetName "Type$i" -TableName "Type$i" -AutoSize
    $dataTable.Clear()
}
$dataTable = $null
$dataAdapter = $null
$conn.close()
$conn = $null

I could also help with this, I've been using PowerShell as a replacement for BOI scripts and V/I for years.

@Myron Stevenson - How about 90M webinar on how you are using PowerShell (vs VBScript) and how it has benefited your coding?

I am not a programmer ( at all ) and I'm purely speculating ( possibly wrongly ) - by the time VBScript is fully EOL  you will have the capability to run the scripting code through AI and have it mostly converted correctly.  Also, the pace of upgrades for Sage 100 is so slow and people can mostly delay upgrading Windows workstations to the point that even if this were announced effective by the end of the year I bet many sites could last another 5-8 years.

Some months ago, I read an article that recommended moving away from VBScript. For processes that are outside of the Sage 100, but connect to Sage 100 data,  I've been using PowerShell for the past year. It is more capable than VBScript and takes fewer lines of code to do something. Currently. to run PowerShell scripts they must be launched with the PowerShell interpreter. It would be a major investment by Sage to provide PowerShell scripting within Sage 100. As Microsoft hasn't announced a hard stop on VBScript, there might be three to four years to implement something within Sage 100 for UDS. That is a very short time for Sage 100. The product planners at Sage might also see this as an opportunity to move customers who need UDS to other accounting platforms. The capability of UDS and been a great benefit for customers using Sage 100 to tailor it to their needs. Without UDS in Sage 100, I would think many would seek something else. 

Wayne has a good point regarding the glacial pace of Windows and Sage 100 upgrades. An EOL date for VBScript hasn't been announced yet. It might be after mine.

------------------------------
Myron Stevenson
Consultant
Clearis Consulting, Inc
Duluth, MN
218-525-6720
------------------------------


Original Message:
Sent: 07-07-2025 16:29
From: Myron Stevenson
Subject: VBScript deprecation

A webinar or breakout session at 90Minds could be helpful. There is a wealth of information available on the web that can help anyone effectively use PowerShell. For example, Doug Finke wrote a module for PowerShell that enables various tasks with an Excel file. Excel doesn't even need to be installed.

Below is a small PowerShell Program that extracts data from CI_Item and puts each record type on a separate worksheet within an Excel workbook. Doing this in VBScript typically requires installing Excel and involves additional lines of VBScript code. PowerShell is very efficient for coding.

Import-Module -Name ImportExcel
$Sage100ExportPath = "C:\Powershell\CI_Item.xlsx"
$Sage100ExportPath
Remove-Item $Sage100ExportPath -ErrorAction Ignore
$conn = New-Object System.Data.Odbc.OdbcConnection
$conn.ConnectionString = "Driver={MAS 90 4.0 ODBC Driver}; UID=MGS; PWD=XXXXXXXX; Company=ABC; Directory=C:\90\V2022\MAS90; Prefix=C:\90\V2022\MAS90\SY\, C:\90\V2022\MAS90\MAS90\==\; ViewDLL=C:\90\V2022\MAS90\MAS90\HOME; LogFile=\PVXODBC.LOG; CacheSize=4; DirtyReads=1; BurstMode=1; StripTrailingSpaces=1; SILENT=1; SERVER=NotTheServer"
$conn.Open()
$dataTable = New-Object System.Data.DataTable                           
$cmd = $conn.CreateCommand()                                            
foreach ($i in 1..5) {                                   
    $cmd.CommandText = "SELECT * FROM CI_Item WHERE ItemType = '$i'"    
    $dataAdapter = New-Object System.Data.Odbc.OdbcDataAdapter $cmd     
    $dataAdapter.Fill($dataTable) | Out-Null                            
    Export-Excel -Path $Sage100ExportPath -InputObject $dataTable -WorksheetName "Type$i" -TableName "Type$i" -AutoSize
    $dataTable.Clear()
}
$dataTable = $null
$dataAdapter = $null
$conn.close()
$conn = $null

------------------------------
Myron Stevenson
Consultant
Clearis Consulting, Inc
Duluth, MN
218-525-6720


Original Message:
Sent: 07-04-2025 12:35
From: Steve Iwanowski
Subject: VBScript deprecation

I could also help with this, I've been using PowerShell as a replacement for BOI scripts and V/I for years.

------------------------------
Steve Iwanowski, NextStep Technology Advisors, aka DSD Lancaster PA ¯\_(ツ)_/¯


Original Message:
Sent: 07-03-2025 19:27
From: Jeff Schwenk
Subject: VBScript deprecation

@Myron Stevenson - How about 90M webinar on how you are using PowerShell (vs VBScript) and how it has benefited your coding?

------------------------------
Jeff Schwenk
Owner
Bottomline Software, Inc.
Waynesboro VA
(540) 221-4444

Improving bottom lines for over 25 years!


Original Message:
Sent: 07-03-2025 09:27
From: Wayne Schulz
Subject: VBScript deprecation

I am not a programmer ( at all ) and I'm purely speculating ( possibly wrongly ) - by the time VBScript is fully EOL  you will have the capability to run the scripting code through AI and have it mostly converted correctly.  Also, the pace of upgrades for Sage 100 is so slow and people can mostly delay upgrading Windows workstations to the point that even if this were announced effective by the end of the year I bet many sites could last another 5-8 years.

------------------------------
Wayne Schulz
wayne@s-consult.com
Schulz Consulting
(860) 516-8990
CT


Original Message:
Sent: 07-03-2025 09:08
From: Myron Stevenson
Subject: VBScript deprecation

Some months ago, I read an article that recommended moving away from VBScript. For processes that are outside of the Sage 100, but connect to Sage 100 data,  I've been using PowerShell for the past year. It is more capable than VBScript and takes fewer lines of code to do something. Currently. to run PowerShell scripts they must be launched with the PowerShell interpreter. It would be a major investment by Sage to provide PowerShell scripting within Sage 100. As Microsoft hasn't announced a hard stop on VBScript, there might be three to four years to implement something within Sage 100 for UDS. That is a very short time for Sage 100. The product planners at Sage might also see this as an opportunity to move customers who need UDS to other accounting platforms. The capability of UDS and been a great benefit for customers using Sage 100 to tailor it to their needs. Without UDS in Sage 100, I would think many would seek something else. 

------------------------------
Myron Stevenson
Consultant
Clearis Consulting, Inc
Duluth, MN
218-525-6720