Verify you installed the correct Avalara client version at the server and that you are connecting to the same SQL Server and database from your laptop and from the client server.

Thats the scary part.... It's the same DB and SQL Server...  It makes zero logical sense. Same program, same DB, only difference is the environment - ones a Local install the other is a Remote Server.  

The last version I have is 7.80 but the Services column is defined as varchar (100), if that's the field you're referencing. Here are the queries that issued against the database by the UI (insert CompanyID) where it might break down:

Create the temp table for the country grid, insert data and select the data to populate the UI. Note the name of the country is limited to varchar (30).

If you are having problems with UI populated differently when the same queries are issued, it might be anything from how your database compatibility, legacy and parameterization is set to how the ODBC or the communications layer is interfacing with the application, or combinations of both. 

It's probably simpler than that but my open question would be what "field" you're referencing as having been modified.

Forum won't let me post the SQL code execution in any format.

The field that I changed from 30 to 50 was Services on TAVConfiguration.    What version are you running?  Could you send me the current definition of TAVConfiguration?  

Looks like there were updates in 7.8 - 8.00 that Avalara didn't include in their 8.10 roll out. 

Hi Contefication, 

Just checking in, curious if after clicking reply, you went to Insert > Code. This gives you a pop up screen where you can insert sample code.

Ersi, off-topic but I had tried that as well, forum software wouldn't allow the insert using any mechanism.

At this point, you should trace the queries. Here is 7.8 Schema:

[dbo].[tavConfiguration](
    [AccountID] [varchar](10) NOT NULL,
    [LicenseKeys] [varchar](50) NOT NULL,
    [URL] [varchar](50) NOT NULL,
    [CompanyID] [varchar](3) NOT NULL,
    [ExpiryDate] [datetime] NULL,
    [DisplayWarningMsg] [smallint] NULL,
    [EnableTaxCodeMapping] [bit] NULL,
    [UDF1] [bit] NULL,
    [UDF2] [bit] NULL,
    [EnableEntityUseCode] [bit] NULL,
    [SendItemGLAcct] [bit] NULL,
    [EnableLogging] [bit] NULL,
    [TimeOut] [smallint] NULL,
    [RetryOpt] [smallint] NULL,
    [DelayBtwRetry] [smallint] NULL,
    [ShippingChrgsTaxCode] [varchar](25) NULL,
    [RestockingFeesTaxCode] [varchar](25) NULL,
    [AvaTaxEnabled] [smallint] NULL,
    [ChkAddrBeforeTaxCall] [bit] NULL,
    [ResumeAddressValidation] [bit] NULL,
    [AvaTaxOnDemandEnabled] [smallint] NULL,
    [STaxSchedule] [varchar](30) NULL,
    [AvaAddrEnabled] [smallint] NULL,
    [AddressUpperCase] [bit] NULL,
    [AddressMap] [int] NULL,
    [ResumeBatchAddressValidation] [bit] NULL,
    [BatchAddressAcceptanceOpt] [bit] NULL,
    [EnableTaxClassMapping] [bit] NULL,
    [Services] [varchar](100) NULL,
    [AvaCredential] [datetime] NULL,
    [TaxSchedule] [datetime] NULL,
    [LastTimeStamp] [datetime] NULL,
    [CountryMap] [datetime] NULL,
    [CompanyCode] [varchar](25) NULL,
    [CompanyVerified] [datetime] NULL,
    [UserID] [varchar](max) NULL,
    [Password] [varchar](max) NULL)

Thanks!  

This just in - we have our first instance of the error message on a local install.  So it seems Azure is not the problem..  That eliminates alot of variables and makes me think its permissions.. perhaps ability to read/write certain folders ( Already checked the Avalara and AV folders on C drive). I wonder if there is something else it is trying to access.

This would appear to be UI other than Options, so try running the address through the Avalara API manually. Verify the return is valid and fits within the defined schema in tciAddress. There also might be problems if you are trying to validate addresses outside the US or are entering too much or not enough address data on a single line.

There are some documented rules on address verification with Avalara, including that only 3 address lines can be verified and the address must generally include line 1 with a city, state/province (region) or postal code (just a postal code works in certain circumstances).

Depending on how they are raising messages, there are some detailed API return messages that might be problematic, like: "The address was found but the street number in the input address was not between the low and high range of the post office database." or "An exact street name match could not be found and phonetically matching the street name resulted in either no matches or matches to more than one street name." at 158.

Your other post, may indicate the client was not installed under the correct permission set. That could be the Sage or the Avalara components since they are different installs. Generally this is why the client install should be performed using a local administrator account. There could also be domain, group or user policies that are affecting the client.

You could use a number of different tools to review details of the processes as they run. You can also monitor network traffic using a packet sniffer/monitor. Either way, you need to narrow down the potential cause(s) because there are still too many.

The addresses are valid, I'm able to validate the same customer number on a different machine.  We performed the installation using local admin rights and we selected the Run as Admin option on the installation.  It is likely due to some specific computer level permissions but without ANY form of documentation, and poor support from Avalara we're stuck trying to guess what it can be.   We've tried several tools in house  (including ProcMon which turned up nothing extraordinary) and got various departments involved from servers, network, security, and now general IT involved and there is no rhyme or reason why the same installation functions on one machine but doesn't function on another given the same installation process being followed.

The error message is not to do with address validation - it pops an error before it even gets to call the program file - 

Those are unhandled VB errors probably in one of their dlls. The only way to narrow it down further is to see if it works when run as Administrator. If it does, it is rights or something specific to that server. If it doesn't, it is something specific to the installation and/or the server, that could also be an incompatibility with another application or the configuration.

These are 32-bit programs, so they are more sensitive to the environment. You could also review permissions on each exe and dll in the AV folder or even try changing the compatibility on the dlls. Each exe and dll should have read/write and generally read/write on the Sage Software folder. There is a registration for each of exe and dll in the registry as well and some may require workspace on the drive. This is generally the users folder but it could also be ProgramData

Those are unhandled VB errors probably in one of their dlls. The only way to narrow it down further is to see if it works when run as Administrator. If it does, it is rights or something specific to that server. If it doesn't, it is something specific to the installation and/or the server, that could also be an incompatibility with another application or the configuration.

These are 32-bit programs, so they are more sensitive to the environment. You could also review permissions on each exe and dll in the AV folder or even try changing the compatibility on the dlls. Each exe and dll should have read/write and generally read/write on the Sage Software folder. There is a registration for each of exe and dll in the registry as well and some may require workspace on the drive. This is generally the users folder but it could also be ProgramData