i have been working on a project using Visual Studio 2015 along with vb.net and mysql. I deployed my application using ClickOnce to my company server then installed on all the computers in my company. It is working fine. Recently, i have it installed on three new computers which has the exact same os and specs with the existing computers, however, the application installed on the three new computers showed a very significant difference in performance comparing to the existing computers, it is much slower in the new computers.
I have checked through
the networks
the connection to MySql database
the memory it consumes
the .net framework version
but it is all exactly the same with the existing computers. does anyone have any idea what might be the cause? Or anyway to troubleshoot this problem?
Just add timers, stopwatches, etc to instrumented builds. In fact, in an application of any size I build-in, from the off, at least a skeletal diagnostic system with a display window and stopwatches that can be used to time specific bits of code - typically database queries. With that in place, it's simple to add specifics to produce instrumented builds to drill down to any problems that only occur on end-users' machines. You can also download DbgView from Microsoft and use that in conjunction with Trace statements in your code.
Related
I have a handful of MS Access 2010 databases that are used to keep track of various things for my group. Each Database has a dedicated back end and each user has a local copy of the front end (*.accdr) and 2010 access runtime. Only three of us have full versions of Access. Each DB has up to 6 users and some users have multiple DB's they use regularly. One user in particular has multiple problems with these DB's. One of them has a form where you put criteria in some text boxes, click a button and another form opens displaying data. Everyone else has this perform seamlessly. On hers, it throws up a dialog box asking for the criteria a second time. This is pretty universal across the DB's that she uses. On another DB, Clicking a button triggers a macro to export of a query to a MS Excel spreadsheet. This will generate an unspecified runtime error and then shutdown the entire frontend. Again, this works fine for other users.
I have systematically gone through and tried each DB from each user's computer. I have checked and rechecked the source *.accdb files I generate the front ends from. The problem seems to exist only on this user's computer.
She does have a full copy of Access 2010, but she doesn't ever use it. She also has 2010 runtime. All of our machines are connected by Ethernet to the server where the Back ends are stored.
I would expect the front end to behave the same way on her machine without unexpected pop ups or runtime errors since it behaves as it should on every other user's machine. I don't know what to look for now, and I am not inclined to throw up my hands and blame a bad setup on her machine. Is there some logical steps I can take now, since IT support is one place no sane person in my office wants to do (bad for the blood pressure). Any help, advice, or even Mystical Incantations would be appreciated.
This is a common occurrence.
The HUGE MASSIVE tip-off is that the accDB works, but the accDE (pre-compiled) does not.
And the next HUGE MASSIVE tip-off is compiling the accDB to an accDE on that particular machine ALSO works.
The reason and problem for this is that the version of Access running on that machine does not match the save version that you are running on other machines. (Specific the machine used to compile the accDB into the accDE).
While of course you are running access 2010 on all machines, the problem is the SP update version (Service Pack(s) installed).
Keep in mind that the runtime is NOT updated by windows update.
Keep in mind that running the office SP update will NOT update the runtime (but this will only apply to runtime only machines).
So, on your dev computer? Well automatic updates can roll out a SP update to office 2010.
However, automatic windows updates NEVER update the access 2010 runtime. You must install the 2010 runtime SP updates manually. So with a mix of runtime and full editions?
Well, the machines with full edition will wind up with SP updates occurring (they over write the runtime on those machines). In fact, you can’t install both full and runtime on the same machine. The installer allows this, but it is a “fake” install, and installing the 2010 runtime on machines with full edition in fact does NOTHING!! (Well, it does create a “fake” entry in the list of programs installed – but it DOES NOT actually install the runtime, since it would overwrite the full edition that already exists on the machine).
On computers with the full edition, then installing the SP updates to office, or even allowing windows update to do this will NOW cause the 2010 version to be DIFFERENT then your developer machine.
The reason why the accDB works is because Access (even the runtime) will detect that the “sp version” is different, and re-compile the VBA on the fly. Even the stand alone runtime version is able to re-compile the source VBA code.
However, with an accDE?
The code is pre-compiled, and thus no on-the fly re-compile can occur. There is no source code. The accDE should and often MUST be run + consumed by the SAME sp update version.
To reduce, or all but eliminate this issue?
Well, on your dev machine, make sure the sp2, or sp3 update to office has been applied.
On the target computers? If they are runtime only, then you MUST install the sp2 or sp3 update to the access runtime. I cannot stress that you MUST download and install the SP2 or SP3 update for the access runtime. The office sp update WILL NOT work nor will it update the runtime version on runtime only machines.
Because of the above?
I recommend you download the 2010 runtime. Download the sp3 2010 runtime update, and “slip stream” the sp3 update INTO the 2010 runtime installer.
You can then provide the customer site (or your site) with a folder on the server with the runtime to install, and WHEN you install the runtime, then the sp3 update will be included in that install.
If you (or your IT department) does NOT know how to slipstream in the sp3 update, then simply ALWAYS have then install the 2010 runtime, and then ALWAYS install the sp3 update for the 2010 runtime.
Doing the above will eliminate the issue of the AccDE having been created and compiled with a different release version of access.
Last but not least?
No question you want to continue using a compiled accDE, since with the runtime, then any un-handled error with an accDB will not only spit out an error message, but shutdown the whole application.
So:
With accDE:
Errors NEVER re-set global or local variables.\
Errors will NEVER cause a shutdown of the runtime.
Even un-handled errors will NOT cause a shutdown of your application.
Un-handled errors will NEVER re-set local, or global variables they will ALWAYS no matter what retain their values for the duration of the appcation session.
With accDB and runtime:
Any un-handled error will blow out all local and global variables.
Any un-handled error will then shut down the runtime after display such errors.
Bottom line:
Using an accDE is thus vastly far more reliability then an accDB when using the runtime.
OK, First of all, thanks for all your suggestions in the comments. We figured a method to keep my user working, so I will put it here.
We reasoned that since the executable ran fine on multiple machines, there may have been some sort of unknow quirk in my users machine that was causing the issues. I started my re-making the front end in the normal way and pushing it out to just the one user. It failed just like before.
Since she had a full copy of Access 2010, we opened the source *.accdb file directly on her machine. That time, It worked just fine.
From there I went, possibly a little overboard. But it worked out.
I opened all the forms in design view. Double check for errors, then save each form in turn. After that, I did the same with the macros. Not making changes, but checking the work.
Next I ran a compact and repair, from the affected machine.
Then I used the affected machine to create a new front end executable.
Lo and Behold, it worked. The affected user now has a completely functional front end.
This is going to make updating the front end a pain in the keister moving forward, but at least now I know what will actually work.
Thank you for your help
I am trying to design a database application for my small business. I've created a number of form driven MS Access databases for use before but would like to create a permanent solution in something more advanced & common.
I was thinking of using mySQL for the database and would then program a C# or VB application to be used in Windows. I do not want or need a web based version at this time but the migration to VB.net in the far future may be something I'll look into.
I know I can use a MS Access backend for my windows application without having to install MS Office on any or all the computers the program will be run for.
But here is my question. Is it necessary to install mySQL Server on the PC hosting the database, on all the PCs accessing the database or can I just use the database file as the backend and Visual Studio will have all the necessary tools I need to access it?
If I have to install the server I may just stick with the MS Access database as the needs for an excessive amount of database storage won't ever be an issue.
You'd need to install MySQL server on the Server hosting the database. The clients would then connect via the network. You will however need a driver to access the MySQL-Server with VB.NET on the client machines. A simple DLL-File might be enough, though.
If you are looking for a file-based database solution have a look at SQLite. But you will have to watch out for concurrency issues here.
A project with the following technologies and components has surfaced: to up a Web stack solution initially composed with Ubuntu, JDK, JBoss, Spring MVC 3.0+, and MySQL.
In planning this project, I have been struggling to find answers to the following questions for first steps, best practices, and sequence:
1) Does the JDK (and JBoss) need to be installed as ‘root’? (I have seen articles that mention it is not a good idea to operate in root unless absolutely necessary due to the fatal consequences.)
2) Does Ubuntu need to be installed as a Server in order to accomplish all this, or can it also be installed as a Desktop? I have not been able to determine if having a JBoss and MySQL need to be installed on top of Linux as a server.
3) Does Maven need to be used within Spring STS in order to get JBoss, and MySQL (and in the future Hibernate) to work successfully together?
4) My intent is to install in this order: a) Ubuntu -> b) Java -> c) JBoss -> d) Spring STS -> and e) MySQL. Are there any blatant conflicts in this sequence?
JBoss will require Java (recommend Java 7) before it will do anything. I don't think it really "installs" per-say, but rather just unpacks to some directory (even if you install from the package manager, it just really extracts itself). I question your need for Spring since JBoss and Java EE in general really does everything Spring does, and better now-a-days. Unless you have a specific requirement for Spring, I'd question this extra dependency.
For linux - in a high level, any OS can be a "server", all it needs is to be capable of serving things (web pages, ssh connections, etc). In M$ world, different "levels" of the OS have been specially designed based on anticipated task/workload. So for example, while Windows 7 can indeed run as a server, it was not designed for it and therefore may not be optimized or include helper utilities and tools to make life easier as a sys admin of the system. Windows Server on the other hand does include all the "normal" server tools and lots of goodies to make maintaining and setting the server up easier.
In linux land, this is no such thing. Linux is the kernel that talks back and forth with the bare metal, etc... and Distro makers will take that and build an OS around the kernel, basically just attaching any packages they feel their distro needs... such as wget, or cat, or any other standard userland apps, plus some non-standard such as mysql or java or whatever they want.
Now, some distributions of linux will tailor themselves at being "server" ready, while others will tailor themselves at being a desktop OS. The difference? It's really just whatever default packages the distribution maker decides to include or not. For example, the overwhelming majority of linux servers are run completely headless, and therefore there is absolutely no reason to have X11 and a huge bloated GUI environment installed and/or running on that system... it's pointless. Also, an "average joe" user does not need MySQL installed by default on his desktop system since it would only bloat his system and he likely won't ever use it.
So basically it comes down to default installed packages.
Some linux server distros take this further and exercise extreme caution when making updates, patches, or new releases in the name of stability and security, while on the other hand most desktop distros are more haphazard with their updates since if it breaks a home users web browser, it's probably not a huge deal... but if a server update breaks the webserver application stack, now that's a serious problem.
So you'll find server OS's like CentOS (based on upstream RHEL) are extremely slow to bring in the "latest and greatest" features that desktop OS's get early on. Their goal is high security and long term stability.
Now, for Ubuntu. While I certainty know a lot of folks run Ubuntu as their server OS choice (partly due to Amazon choosing Ubuntu as the default linux VM for their ECS cloud), but I'd really question this. Ubuntu is not focused on being a server. It's focused on being a great all-around desktop oriented OS. Yes the LTS version is meant for long term stability, but it's based out of a desktop OS, so it's still not the focus.
IMHO, I'd go with CentOS because it's free and completely binary compatible version of RHEL - and RHEL is the de-facto standard for enterprise-grade linux servers. Be aware though, the RHEL way of doing things is a bit different than the debian way -- so there is no apt-get, you must use yum install instead. Startup scripts are different and some ways of doing things are different, but really, once you know linux, you know linux.
EDIT: Also check into Jenkins - its a free opensource continuous integration system that runs on JBoss or Tomcat or any other container, and can automagically pull your code from a repo (github, git, svn, etc) and compile/package it then push it to live deployment. You setup your ANT or Maven build scripts, and it can kick off on a schedule or however you configure it.
EDIT EDIT: I'd also recommend using OpenJDK -- as it's likely included in your package manager (for just about every disto) and will be more updated than the oracle version if it's in your package manager too. I've found most "server" distros will have OpenJDK 7 while only having Oracle java 6 in their package managers. Also, installing it via the package manager will enable you to keep it updated a ton easier.
Installed as root, why not? Run as root, probably not a good idea.
If you want a desktop, install a desktop distrib. If you want a server, install a server distrib. This doesn't change what can and can't be run in the OS. It only changes what is installed by default.
Maven is a build tool. JBoss doesn't care how you build your app. All it cares about is if the application you deploy is a valid Java EE application.
No. You need an OS, so Ubuntu must come first. JBoss and (AFAIK) Spring STS need a JRE to run, as they're Java applications, so Java should be installed before them. MySQL is independent of JBoss, STS and Java, so you can install it whenever you want.
Note that if you're struggling just with this installation part, be prepared to suffer with the rest. Building a Java EE webapp is not a piece of cake, and you should probably find some experienced developer to help you, as it seems you're only beginning with Java.
I am forced to finish my Windows project on Mac - Its a Visual Studio C# connected to MySQL database. I've installed it quite nicely on Virtual box and all looks fine (well... except the look of the VB itself, I can't change the screen resolution for some reasons so I use only about 50% of screen).
When I told this to my friend, who is quite passionate about Macs he suggested me Parallels, and even offered his copy. While it looks nicer and in theory is "better" I am not really able to work properly on connection between VS and MySQL: when I'm trying to get through wizard to add data sources I either get error that system cannot connect to ODBC (yes, I've reinstalled connectors) or wizard proceeds, but disappears after pressing any button (i.e. while I'm trying to type "localhost").
have anyone had such problems with Parallels? Or should I try to work on Virtual Box and fix the screen problem (any hints on that would be appreciated).
I have been using Parallels with Visual Studio / SQL Server for over 4 years by now, and it works like a charm! If for whatever reason your virtual machine might get slow, I can recommend you to get some extra memory for your beloved Apple.
Especially when running Windows, Parallels has some fancy integration tools, which gives it some pro's in comparison to VirtualBox.
My current Mac has 8GB of internal memory with an SSD drive. I have assigned 4GB for my virtual machine. I don't notice any slow-downs on OSX, nor on the virtual machine. In fact, my Windows boots faster than one of my native Windows machines!
We are running Windows Server 2008 R2 (64-bit), SQL Server 2008 R2 (64-bit) and a 32-bit Java application all on the same server. The application uses the Microsoft JDBC Driver v3. The application can use Java 5 or Java 6, but both as 32-bit JRE's. So the driver can be type 3 or type 4.
Here's what we see: When the application runs, database access can become quite slow when under any type of load. When you remove the load, it will be okay. Put it under load again, and it becomes slow.
The complex part of this is: If we run the application on a separate but equal server from the database, it is not slow.
So it appears that the behavior of the driver is different. When driver and database are on the same server (reached through the local stack), then the mix of 32-bit and 64-bit slows things down. When the driver and database are separate from each other (reached through the network), then the mix does not cause a slow down.
Any thoughts?
We do not expect the application and database to be on the same server. But we have sales people who demonstrate on a single laptop, so they need it all together. Currently, we look like we will be forced to isolate using VM's or similar. Not what sales wants.
Technically, we are curious why introducing the network makes a difference.