I had a single Starship profile that somehow got corrupted, for one user it would take an additional 10 seconds - 2 minutes to view shipments that had been processed that day. I actually found the corrupt setting within the database and fixed it but the easiest way to fix this issue is to make the users a new profile.

The way to confirm it is a profile issue is to log in as a different Starship user on one of the problematic workstations and see if the issue goes away. If the issue is fine on the same computer as a different Starship user then it is a Starship profile issue. Other than digging through the database (which V-Technologies doesn't want you to do) the easiest way to fix that issue is to create a new profile with the same permissions through the Starship server manager.

Just remember if you make a new profile you will need to set up all of the preferences, printers, and documents again for that user on that workstation.

If that doesn't work I have some other suggestions for you, let me know how it works out.

Thanks for the suggestion, didn't help.

Somethings that have happened in the meantime:
I got an upgrade to v 16.1 and the MAS MIFS Installer fix.
Broke our ship-gear, but I fixed that without vtech's help. (I wonder if that's causing conflict... HMMMMMM)

It's just the BOI is so darn slow, and I don't know what changes I can make to the OBDC, etc. to get it to move data any faster. I've got 12 GBs Ram on the server and a 2mb database... this is just sad.

One of my suggestions was going to be MIFS but I take it you already have that, are you running Starship and Shipgear? I would wonder about port conflicts.

If you disable Windows Firewall on the server and workstation does the problem improve? I would also try disabling antivirus temporarily on both to see if that helps at all. Which document are you bringing in to Starship, Sales Orders or Invoices?

The other thing I would question is DNS, to rule out a DNS issue try adding a host file entry on the workstation having issues for the server by going to:

(if C:\ isn't your root drive replace it with whatever is)

C:\Windows\System32\drivers\etc\hosts

open the hosts file with notepad

add your server name and ip address here, like

192.168.1.1 Sage-Server01
Sage-Server01 192.168.1.1

and then save within notepad.

This will completely eliminate DNS from the equation.

A few other things you may want to try, if you have another company in Sage, like one of the original example companies like (XYZ) XYZ Manufacturing Company, then create a connection to that company by going to Setup>Source Interface>Sage 100 4.1 2015 (on the dropdown menu). Then click the My Companies section and go to Add Company. You may have to go create a Sales Order or Invoice (whichever you are normally importing) in the test company for you to be able to test properly. If it pulls in data from the test company quickly but not your main company then you may have a data issue with your main company. It seems somewhat unlikely because only some workstations are having the issue, but worth testing in my opinion.

Also, have you reinstalled Starship?

I suggest you open a case with V-Tech directly. They don't expose much of their KB and I find it's worth the per case cost to have one of their techs login to look. Most of my customers purchase the installation and the per-call/incident.

Called vtech and they did all they could, it all points to sage.

I'm still situating and am not full stack and only experienced at desktop support, so I'm learning a wild west enviro and these programs from scratch. I'm begging them to get me an enterprise architect... or dba. I'm deff. not full stack myself.

Anyways,

I did the mifs, host files, no change but it's slow as molasses on my test company directly on the server too. At that point vtech blamed sage.(now that I have the server log on to even test that. Sigh). I wonder if its hdd read speed or something with everything from dns to these programs on one server. I've a call scheduled with a sage vendor soon to help see about premium over advanced sage too.

At this point I'm thinking of building a test machine with fresh sage, fresh starship, and the rf guns with two hdd disk one os, one data to see if that helps.

Also, anyone know how important the starship database is? If I can clean install it I will.

I know its rinky dink to have just one machine but the shop is tiny and I'm stuck making it work with no clue, so yeah just grasping straws.

I don't understand your statement of the problem. "Sage seems to take forever to pull up the forms on Starship." ... what does that mean? Are you in Starship when the problem happens? If so, are you pulling up sales orders or invoices? Or are you in Sage when the problem happens? If so, Invoice Data Entry or Shipping Data Entry? Are you using scan guns? If so, which software? It can take a while to move the scanned data into the Sage db if maintenance has not been kept up to date within the scanning folders.

It's the starship client. V. 16.1. that is slow.
It takes a good 12-20 seconds even with the client on the server (not through the network) for Star-ship to read the BOI interface, write to it, etc. They are shipping from the order
From what I understand, it went on slow (basically it was useless from day 1 and the vendor whatever at the time didn't sort it).

It is literally anything that forces Star-ship to talk to Sage that is slow. Scanners are not active at this moment as starship is so slow there's no use of the things till this is sorted. I didn't here of performance issues when they were up being any "worse"

Everything on the forums here is just "turn off AV, etc." but that's all done.


I wasn't here for any of the install, etc. and it's not like I have ITIL level documents or the right access; yet here's what I can tell you

Windows Server 2012 R2 Standard 6.3.96
Xeon e5
64 bit,
16 GB,
10 gb paging


Sage 100 Advanced 2013 ERP, running as application
v. 5.00.7.0

Starship16.1.0


It's connected using the MAS90BOI

We had shipgear on the machine, but it's starship. (we pulled gear, made no diff.)

Scanco guns are installed, but not active at all.


I just have no clue where to even start looking, again... I'm desktop, not a DBA/enterprise/sql person.