I have a client who has a VB 6.0 application with MS Access as backend. But, now the Access is unable to take the load. So, we are now considering to shift to SqlExpress Edition. Also, we will convert VB6.0 application to c# based Winforms. My questions -
1) Can SqlserverExpress support 10 users concurrently? If not SqlExpress, then what other options are available?
2) Should I first convert VB 6.0 to C# application? Because, if I transfer data to Sqlserver, will VB 6.0 application continue to work?
thanks
Yes it can
You don't need to convert your app, but Access and Sql Express - are different database engines, so you will need to adopt your app to sql express
Note, that sql express prior to 2008 R2 can handle up to 4 Gb databases, while 2008 R2 can handle up to 10 Gb per database.
1) SQL Express allows over 32 thousand simultaneous users. The only real limit is database size, which is 10 Gigabytes.
2) You'll need to at least modify the VB 6 application to have the correct connection string before it will work with SQL server.
I am curious though why you say that Access (the JET database engine) is unable to take the load. Usually 20 or even more simultaneous users are no problem.
If product is for in house use and doesnt generate cash you can use oracle. Its free to use unless your app is for commercial use.
One question to ask is after how many users does the system slow down? And if it is slow with one user, then this might be some software design issue and not necessary the "load" on the server. There also the issue of the type of connection WAN or LAN. In fact you can read about this issue in the following article:
http://www.kallal.ca//Wan/Wans.html
The above in a nutshell explains why the Access data engine does not work well on a WAN.
Also migration of data to SQL server without determining what particular issue is causing the slowdown could very well result in a further slowdown. In other words often just up-sizing data to a server database engine will not solve performance issues and in some cases it can become worse.
In fact in many on line Access forums we often see users complain of a slowdown when moving the back end data file from Access to SQL server. So just moving to SQL server without taking advantages of SQL server features does not always guarantee a performance boost.
The other issue you want to determine here is if the VB6 program uses ADO or DAO. Either data object model is fine, but ADO would suggest LESS code will have to be modified then if the application is based on DAO.
Another issue is you not mentioned how large tables are, and the number. So say 30 to 50 highly related tables, and say a small number of rows (say 200,000) in some of the tables should run just fine with 5 to 15 users. If your user count is only about 10, and your table row counts are small as noted then performance should be ok, and if it is not, then as noted you might be able to keep the application as is and moving the data to SQL server may not yield performance gains without further code modifications. And of course SOME code will have to be modified to work with SQL server - how much will depend on the data object used, and how much code there is over all. (more recordset code = more chance of needing more code changes).
If you do decide to convert from Access to SQL Server Express, there is a migration wizard which can give you a quick start with that process. Here's the link
Related
I'm working on a database driven program in Visual Studio 2015, in C#, Windows Form Application, and I'm using SQL Server 2014 for my databases, downloaded the most recent version from the MSDN site.
I've got it working well. But if I want other users on other computers and different versions of Windows, this would require them to have SQL Server installed, correct?
Basically the app is used for storing current medications, moods, a mood quiz, symptoms, etc.. and I store all the results in SQL Server databases. They can be edited, deleted, etc through the program's GUI. Do the users need SQL Server installed to use this app?
If so, is there an alternative to keeping databases without having to have the SQL Server connections, or is there a way to do this without the users having to have SQL Server installed? I don't want remote connections to me, I want it standalone.
Does this make any sense? If not, I can explain more. I know way back in the days of Visual Basic 4 I was making, reading and writing databases without SQL. But that was 16 years ago. So I'm wondering what the easiest solution to this is. Thanks!
In other words, you want a database that you can a) distribute to end users freely and b) that will 'connect' just to the copy of the database they have stored locally.
Here are a few options ---
SQLite over ODBC is as-easy-to-use as MSSQL, the driver can be found here:
SQLite ODBC
Use ConfigurationManager.OpenExeConfiguration to read / write your app config .xml file and use it as a key / value store. I can provide examples if needed.
Dynamically create an Access database, it should work as well as MSSQL for most things, with less overhead. Here's how:
Create an Access Database
Use SQLIte DLL. Details on SO
create-sqlite-database-and-table
I understand that this is painfully generic and broad. Nonetheless, all the answers on wikipedia and yahoo (none here that I can find) are pretty useless.
I know T-SQL, C#, etc to some degree. I understand the idea of a database. However, I have NO idea what I created when I made a "server" on my computer through Msft SQL Server. Now I can make databases on that server, and I can connect to them with Visual Studio (sometimes) to use with LINQ or "raw" calls.
Please help me understand (or direct me to an article) of what this myComputerName\SQLEXPRESS (SQL Server xx.x.xxx) thing is. I assume the databases are stored locally...somewhere. SQL Server provides access to the DB files? Why can't they be accessed directly?
Thank you if you even read all this. I really can't narrow the question down.
I guess one specific question is "Can I access the databases without SQL Server running?" Where do I even get the connection string?
You are asking multiple questions, here.
However, I have NO idea what I created when I made a "server" on my
computer through Msft SQL Server. Now I can make databases on that
server, and I can connect to them with Visual Studio (sometimes) to
use with LINQ or "raw" calls.
Please help me understand (or direct me to an article) of what this
myComputerName\SQLEXPRESS (SQL Server xx.x.xxx) thing is.
The layout of a database server is as follows:
Server
Instance a
database aa
database ab
...
Instance b
database ba
database bb
...
...
So, when you install MS SQL Server, you install a MS SQL Server "instance". In this "instance", you can create a number databases. Each database has database files, the exact location of these depends on the settings you chose during installation.
I guess one specific question is "Can I access the databases without
SQL Server running?"
You do not usually open dbf(mdf -ldf) files (the database data files) without MS SQL Server, why would you want to ? You should use the backup/restore features inside MS SQL Server.
Where do I even get the connection string?
http://msdn.microsoft.com/en-us/library/system.data.sqlclient.sqlconnection.connectionstring%28v=vs.110%29.aspx
The "server" is a process/service running on your computer which can be connected to over the network and provides the API to access your database.
"Why can't they be accessed directly?" Is like asking why do I need Word to view Word files, can't I use Notepad for that. Sure you can, but not really.
Another reason is - imagine multiple processes need to access the database. If each reads and writes to the same files, something WILL break if they don't coordinate. Having a separate server process encapsulates all this.
"Can I access the databases without SQL server running?" I mean yes but actually no.
If you want a database that your program accesses directly (or let's say, your program is also the database server in a sense) - then you can use sqlite, or for simple tasks there are also ODBC drivers for CSV, so you can use CSV files as if they were a database. A dedicated SQL server is always better for bigger more complex tasks and data models though.
I have looked at a few stackoverflow forum posts but nothing fits (or atleast I dont think so) what I need help with.
I'm looking for general advise, my company has 'tasked' me to look at moving some data from tables stored in our parent companies databases into a database of our own that has all the information we need in one place.
For instance if we want information that related to one thing, we may have to pull data from several different databases. I think I can get my head around the moving of the data and create a sql query to do it, however we're currently using SQL express as our SQL db (the company is more than happy to buy/create a SQL server but as far as we can see SQL express does what we need it too (feel free to correct me)).
I need to look at scheduling the data move for every hour or few hours to keep the data 'up to date' for when reports are generated using the data.
I have looked at a few programs but the as the queries and the database is on a server 2008 r2 system some of the 'programs' don't like it as they were last updated pre 2010 etc. I have also installed SQL management suite 2012 due to SQL server agent but I cant even get that worked (Service is enabled and I have restarted the DB just still nothing within suite).
I'm not looking (however happy to take the help) for a 'Do this and that and that' type reply but more than happy to accept that amount of help but if you guys / gals can point me in the right direction.
Summary:
-Combining data already on databases from our parent company into a table / DB of our own making
-Currently using SQL Express but willing to upgrade to something else that does the job
-Schedule the data moves for every X hours (Windows scheduling?)
-automating the entire thing so don't have to manually do the moves.
Help on any of the points above would be greatly appreciated and I would 'love you long time' for the help.
JB
There are a bunch of limitations for SQL Express. One of them is that SQL Agent is not supported. SSIS like SQL Agent is not supported.
http://msdn.microsoft.com/en-us/library/cc645993.aspx
Do not fret, you can always schedule a job with Windows Scheduler.
http://windows.microsoft.com/en-US/windows/schedule-task#1TC=windows-7
As for moving the data, it is up to you to select a solution.
1 - Write a PowerShell application to perform the Extract, Translate, and Load (ETL).
http://technet.microsoft.com/en-us/library/cc281945(v=sql.105).aspx
2 - Use the SQLCMD to perform logic like calling stored procedures.
http://technet.microsoft.com/en-us/library/ms162773.aspx
3 - Use BCP to dump and load data.
http://craftydba.com/?p=1245
http://craftydba.com/?p=1255
http://craftydba.com/?p=1584
http://craftydba.com/?p=1690
It is funny how youngsters think they need to spend a-lot of $ to create a solution for a business.
However, Microsoft does supply you with a-lot of free tools.
You just have to put them together for a solution.
PS: I remember about 10 years ago I created a custom ETL solution using VBSCRIPT. Unlike power shell, it is installed on old and new programs.
Good luck!
You can create a console application which executes that particular stored procedure which handles your logic. ( http://dotnet.dzone.com/articles/basics-stored-procedures-net )
Of course using SSIS is much easier but it's not available in SQL Server Express Edition.
I think you should have a look at Integartion Services, which is not available for Express Edition. Have a look at this article to get started with SSIS.
I am trying to migrate from Access Database to SQL server database. Do I need to make changes (for saving, reading, deleting etc. data) to my code as well?
I understand I need to change connection but what about code?
Thanks
Furqan
For the most part, Access SQL Queries are very similar to SQL Server Queries. Therefore, unless you're using Access-specific constructs such as Val, CInt, etc in your queries, you can safely migrate to SQL Server.
It is recommended though, that you thoroughly test the program after migration lest you run into 'strange' errors.
I'm sure the conversion will require some time and troubleshooting. For one, Access through version 2007 uses VBA for the back-end code and SQL Server's programming is quite different from VBA. Developer's transitioning from Visual Basic 6 (very similar to VBA) to VB.NET ran into quite a few challenges.
Also, keep in mind that SQL Server is best used as the back-end storage engine. The user interface is typically written in a .NET language using Visual Studio. SQL Server (at least through 2005 -- I haven't used 2008) doesn't have user interface components like a File Open dialog box.
I have application that requires SQL Server 2000 as database storage.
I do not really want to use SQL Server 2000, but I can user MySQL Server instead.
Application uses ODBC to connect to SQL Server Database.
I would like to know if it is possible to make fake SQL Server which will send and receive data to/from MySQL Server
application <---> odbc manager <---> fake SQL Server driver <---> mysql server
Any one if such thing is possible to make?
If your application simply uses vanilla SQL via the ODBC driver, you should be able to use MySQL with few problems. If it uses specific features of SQLServer, then you need SQLServer - you cannot realistically fake it.
I wouldn't.
You're going to spend so long persuading the two to play nicely to no real benefit. You'll have to do most code the SQL Server way to work in this scenario. Given these, you might as well just bite the bullet and learn to use SQL Server directly rather than trying to tie the two together somehow, I'm afraid.
You can use a provider model and just switch out which provider your using at run time.
Of course, the biggest issue will be in the differing SQL code support. So you will have to take care that all of your SQL is located inside of each provider and stay away from any sort of embedding it in your application logic.. which you should be doing anyway.
Another way is to simply change the ODBC data source at deployment time, but again, you will have to make sure the SQL code actually works in both environments; which is tough.
Typically supporting multiple database back ends is a art form in itself. Simple things like SELECT TOP 100 for SQL Server 2k versus MySql's LIMIT command are enough to keep people from doing this.
There's no real way of "faking" it because the database servers are fundamentally different. You would end up writing a fair amount of code just to translate a sql call from one to the other... Which is a waste of time.
I'd suggest you just bite the bullet and learn MS SQL Server.
This site shows a very simple example of how SQL Server, Oracle, and MySql differ on just one implementation of a select statement.
Not sure why you "do not really want to use SQL Server 2000" but, if you decide you need to and you have a PC with Windows available, you can use the Microsoft Database Engine 2000 Release A (MSDE2000A.exe). It is the real thing and free to use on a desktop.
http://msdn.microsoft.com/en-us/library/ms811304.aspx
I do not think it is available for download from Microsoft anymore but you might be able to find it somewhere else. If you can't find it, your next best option may be to use the 2005 version (SQL Server 2005 Express Edition) and make sure you do not use any new features since 2000:
http://www.microsoft.com/Sqlserver/2005/en/us/express.aspx