How can I deploy Access applications to multiple companies, with linked tables to SQL Azure servers?
I'm planning to deploy the Access programs with Microsoft Access runtime, and I'm assuming that I'll need to include the odbc drivers as well? Is there a way to automatically have Azure create a new server when a company signs into my website and downloads a program, and have the Access program link to it? And is there a way to get around the IP address settings in Azure as well? Because companies will be using the programs on multiple PCs. Or is it possible to utilise that and charge per PC?
If you distribute the application pre-linked, then the user should not have to do anything to consume the data.
When using Access with SQL server you can in general use the standard windows built in SQL driver. However in the case of Azure you do need to download + install the native 11 drivers (so I recommend you use that driver during development and setup).
You can also have code include to re-link to the sql server, but as noted, if your application is “already” linked, then you really don’t have to do anything on application startup. Such re-linking would not be required every time the application starts, but only a “one time” re-link is required say if you’re going to change the database, or perhaps the user logon. How to re-link (DSN less) is outlined here:
http://www.accessmvp.com/DJSteele/DSNLessLinks.html
As noted, you really don’t need the above.
As for IP restrictions, in the Azure setup you can turn off such restrictions if you need a connection that will occur from any location, but that does open up a security hole. (when you first create the SQL database you will be prompted for firewall rules).
All of the above assumes you been developing that Access application with SQL server as the back end (you can even use the free edition of SQL express for development on your local machine).
Last but not least:
Because your connection is occurring OVER the internet, then you speed will be MANY times slower then using a local server. Read the following article to get a “grasp” of this speed difference:
http://www.kallal.ca//Wan/Wans.html
So MUCH additional work is required in Access to obtain good performance when your connection is OVER the internet as opposed to SQL server running on your local network.
Related
I am trying to find a solution to three issues I have encountered recently relating to SQL Server 2014. I am not an expert with this stuff by any means, but I've sort of fallen into needing to learn it in my current role. I went from never using SSMS a few months ago to (Trying) to teach myself how to use SSIS and SSRS. I've made a ton of progress, but now I'm stuck actually getting everything automated the way I want it.
The biggest challenge, and root of all my problems, stems from the fact that I am not a local admin on my machine. It was great to finally get IT to install the programs, but they do not want to give me, or anyone not in IT in my company, local admin access. Apart from asking my director to try to convince them to do so, I'm hoping for some solutions that would mean I don't have to call them every day to run these programs.
My integration server is running, I've got my SSIS packages built, but I can't connect to the Integration Server through SSMS, as I am not a local admin on my machine. I've read about going through dcomcnfg settings for REMOTE access issues, but I'm worried that won't help here since I'm trying to do this from the local machine and it still doesn't work. Any ideas as to how I can change the settings so that it runs for non-admin accounts or just make it work?
SSRS: I've built a report, and want to deploy it, but I don't have access to the reporting services configuration manager either. For whatever reason my reporting server is stopped in the server configuration manager. When I click on it, it says to use reporting services config mgr to tweak settings, so a bit stuck. Appears to be the same issue - not a local admin. Again, are there any settings I can change (getting IT to log in as an admin and walking them through what to change is my only choice, essentially).
SQL Server agent appears to be the same issue...
I could probably run my reports now, but it would be so much nicer to use these programs to the full extent. Any help would be appreciated here. I tried to research as much as possible, but most solutions seem to relate to logging on myself as an admin, running things as admin, etc, and I just can't do that.
Thanks!
You do not need to be local admin on your machine, SSIS and SSAS require Windows Authentication to log on remotely to the server via SSMS and publishing anything to the server from BIDS / SSDT Visual Studio Shell also requires WinAuth, though you can work locally and then swap the package to the server via Ctrl-C, and also instead of deploying SSRS you can login directly to the report manager and upload an RDL file (report). To start and stop SQL Agent services you need Windows Authentication via SSMS (in your setup), but to view the SQL Agent you must be in the SQL Server SysAdmin role (or at a grain level SQL Agent Reader via the MSDB rights.
I recommend you attempt to not get local administrator rights and instead ask 'merely' for rights to read and write to the server drives, and to manage only the aspects of SQL Server and it's services with a domain login on the server. You will require this anyway to check ingress and egress file locations and debug production issues (unless you have FTP to the box).
You do not have access to stop or start SQL Agent from your client SSMS also because I believe you are accessing it via SQL Authentication, which is not ideal or secure. But if you do not see the agent on the bottom left of SSMS it is because you do not have rights. If you see the Agent and it is red then the service is disabled and must be started.
You will need to get direct access to the SQL box (and you do not need local admin to manage SQL Server, just a domain account with some service rights and drive rights). If your system administrators are running SQL Server under Local Admin, then they should not be managing SQL Server in the first place (see my write up hyperlinked below).
The SSRS Team at Microsoft has merged into the SharePoint team, and SharePoint 2013 wraps up all of the BI tools right into it, so that is something you should also consider if you plan on building out a BI shop at your firm, i.e. you may not have to if you already have SharePoint installed.
Good luck, don't get discouraged.
What user account would you recommend running the SQL Server Express 2008 services in a development environment?
I have a simple ms sql 2012 express database & a simple VB Express 2010 application as its front end.
Can I simply host my MS SQL database on Azure & update the application to interrogate the hosted database? This would mean, the application would still be local, but the DB would be hosted. My offices are distributed & if we could do this it would save quite a bit of hassle.
Do I need to use a virtual machine, cloud services or straight hosting? Its difficult for me to understand the subtleties each service.
I've had a look at the azure services information and the documentation is pitched a little high for me. I just wanted to know if this is relatively simple thing to do & if anyone has has any pointers to How To's or Noob guides to azure.
It's absolutely possible and in fact, super easy to set up.
Check out this simple step-by-step instruction on how to set up SQL Server DB on Windows Azure - https://www.windowsazure.com/en-us/develop/net/common-tasks/sql-azure-management/
You can even connect to it from your SQL Server Management Studio just like you would connect to a local database or a database on your network.
Ideally - yes, you can change the connection string used by the VB desktop app to reference the Windows Azure SQL Database instance instead of the local database. That said, SQL Database is not 100% compatible with SQL Server. Be sure to check out the differences at http://msdn.microsoft.com/en-us/library/windowsazure/ff394115.aspx
Can I simply host my MS SQL database on Azure & update the application
to interrogate the hosted database?
Yes, your SQL Azure database is accessible via a connection string, but you have to make sure that you create a firewall rule in SQL Azure to allow your locally hosted or remotely hosted applications to access the database. Everything is turned off by default.
Do I need to use a virtual machine, cloud services or straight
hosting?
I'm not exactly sure what you're asking here, but a VM may be overkill, as that gives you basically a place to host a VM in Azure. You control the O/S, patching, etc. A cloud service (a web or worker role) is a little less maintenance heavy as the O/S, patches, updates, etc. are maintained by Azure and you just worry about your application. Straight hosting - are you talking about hosting on 1&1 or GoDaddy or something? If so, that's really no different than your VB app running locally and accessing your Azure database. For this option, just make sure you have your firewall rules set properly, otherwise you won't be able to access the database.
Hopefully this helps. Good luck!
Azure has some specific requirements that need to be met (like every table has to have a Clustered Index), and it does not support some functionality that is available on "normal" SQL Server (like replication, FILESTREAM data, or data compression).
Other than that, as long as your app meets the requirements, there should not be a reason for it not to work on Azure. The majority of the functionality not supported by Azure is most likely out6 of the scope of what a "noob" would implement, so you probably are safe.
However, Azure might be overly expensive for your needs. It might be cheaper to go for hosting the database somewhere. This would mean you would only have to change the connection string of the application to point to the new database server (though there could be additional limitations imposed by your hosting provider).
Good luck with whichever option you end up taking!
We have an application, consisting of an MS Access frontend (2007, mdb format), a few .net libraries and an SQL Server (2008) backend. I am working on an installer, which automatically installs the MS Access Runtime, our application, our libraries, SQL Server Express and configures everything.
Clearly, the MS Access application and the libraries (running in a normal, non-admin user context) need access to the SQL Server database. What is the best way to grant access to the application?
This is what I came up with. Unfortunately, all of these seem to have drawbacks:
SQL Server Compact Edition: Does not support views.
Application Roles: This seems to be best practice. However, it requires executing a stored procedure before accessing the database (I cannot pass the app credentials in the connection string). Thus, I cannot use this to attach the SQL Server tables as a linked tables in the Access MDB, which is a requirement of our Access application.
SQL Server User Instance: To quote from MSDN: "This feature will be removed in a future version of Microsoft SQL Server. Avoid using this feature in new development work..."
SQL Authentication: Microsoft says: "When possible, use Windows Authentication."
Using Windows authentication and granting BUILTIN\USERS full access: This is by far the easiest solution, but somehow it "seems wrong" to do that...
The application is targeted at a non-technical audience, so asking the user to configure permissions is not an option.
EDIT: Some clarification: It's a "local" application, i.e., the SQL Server is located on the same machine as the application; SQL Server access from the network is neither necessary nor desired. The software (a regular business application for managing stocks, invoices, etc.) will be available to download for free, so it should run in a variety of environments (domain/non-domain, different operating systems, etc.), and IT knowledge should not be required to install it -- apart from the usual "click on setup.exe, confirm UAC prompt, acknowledge the installation directory, etc.". I expect the most common scenarios to be "Windows XP, local admin user" and "Windows Vista/7, local admin user with UAC enabled". Since we want to follow good practices, running the application should not require "Run as Administrator" in the latter case.
#Heinzi write:
Using Windows authentication and
granting BUILTIN\USERS full access:
This is by far the easiest solution,
but somehow it "seems wrong" to do
that...
The usual approach here is to add a custom user group (e.g., "db-users") and put the users in that group. That way you can control exactly who is allowed access.
How about:
Use an Access ADP project, pre-configured to connect to the locally installed SQL Server instance.
Connect using BuiltIn\Users group (or SQL authentication) but grant only the bare minimum credentials. Enough to logon and ...
Call sp_setappprole to "elevate" the client connection to your defined application role's identity.
If sound like you have only got the tie of the iceberg. When it comes to selling and deploying access SQL applications.
I have take a different route. I have virtual computers as standalone workstation and domain server and workstation all virtual.
I have write a scripts they are a combination of VBA and VBScript.
Ask
Is the DB and App to run on single computer or different computers.
If different computer what is the name of the computer the DB is located on.
Is the DB and App to in a workgroup, homegroup or domain environment
Is the DB computer already have SQL Express or above
Is the App computer already have Access or Access Runtime installed.
If yes which version.
Will all or only limited users have access.
If limited what is the user group name of user to be have access to the data.
Does this group already exist
If No List the Name of the Users that Should Be Added to the Group
Also questions about the Admin Users and Group
The script start the virtual machines and goes through a series of steps to rep the MDB and SQL DB for deployment. Then creates an MSI for the Server Install with include a custom script that sets up the environment. Finally packages MDB in a nice MSI.
I have since enhanced the process to allow some questions to be answered at the beginning of the server installation. This means the user groups and users can be selected from the lists in the workstation or domain depending on prior questions asked.
If user the app user is a member of the Admin Group of the Workstation or Domain. They get extra menu options. That allow them to add or remove members from the DB user group for the workstation or domain. This I find is helpful.
I am now moving to the next stage and looking at hosting my assess app as an SasS (Software as a Service) (Rental). So the app can be use in any HTML5 Browser, Windows or Mac as Virtual Desktop or Android and Apple device. Having said that Access is a bit ugly on mobile devices.
When I am up and running I will make the platform available to others.
I was readin this month edition of SQL Server Magazine and in an article about securing Sql Server environment , the author mentioned that developer should try to have the website and the databases run in separate servers for security. I have a shared hosting account and was wondering if it makes sense to buy a second account to move all databases there. Or does it only make sense when using dedicated servers? How would it affect performances on my website?
I use asp.net and have a hosting account with DisountAsp
That article probably doesn't apply to your situation. Running the database on a separate server is a measure to protect against root compromise of the web server hosting machine. I a shared hosting environment the same situation would result in compromising all accounts on that machine anyway. Depending on the particular settings of your hosting, your account database may alreayd be on a separate server.
Besides, with a shared hosting account is very unlikely you'll even be able to query a database from another account.
If you buy a second server, what will it be, a VPS? I imagine you will get more CPU cycles on a VPS with a dedicated database server than a dedicated machine with multiple databases, but who really knows.
Still, your host isn't running websites on their shared database servers, so what's the difference, security wise?
Performance would me my number one driving factor. I mean if someone compromises your web server, unless your connection strings are encrypted, they've got what they need to connect to the DBs.
I'm not sure whether I'm asking the question correctly, but I've been told SQL Server cannot run on a Novell server. Is this true? If yes, why not?
Your problem is your directory service, whether it's Microsoft's Active Directory or Novell's Directory Services (I think it's called).
Sounds to me like your DNS is broken if your clients can't resolve names to IP address.
NOW I see your problem! Sorry dude!
Yes, VERY easy. Kinda.
SQL Server used to be able to talk IPX (the netware protocol) but I think Netware will now talk TCPIP, and you can run IPX and TCP/IP on the same network without an issue - windows clients can run both at the same time, 99% of routers handle all protocols etc.
Windows (XP/2003/etc) can run the netware client, so it can talk to shares etc.
Use the SQL Server logins (rather than windows integrated logins), and it'll work from anything - we have Java on Linux talking to SQL Server on windows just fine :) It's all in the connection string: userid=username;pwd=whatever;server=yourserverhere; etc. But you MUST use the SQL Server Configuration Manager to set these up - the default is shared memory, so you have to enable TCPIP etc.
You may have to be more specific about what a "novell server" is. From what I understand, Novell servers run some form of Suse linux. Sql Server is a windows only product.
My company, however, does have clients that run Novell networks, and we do run Sql Servers on their network. But they're hosted on a win box...
SQL Server is a Windows app. Novel is either one of:
Novell
or
Linux
Neither of these are windows :) It's like asking "why can't I run this Mac application on my windows box". Or "why will my petrol car not run on diesel?"
There are old version of Sybase, which SQL Server sprang from, which COULD run on Novell Netware, but you'd need to find a software museum to find one, I think!
If you need a SQL Server, I'd suggest you either get Small Business Server, which comes with MSSQL, or install one of the free editions of SQL Server on XP or windows 2003 server. Or use something like MySql, Postgress etc on Linux.
I'm not sure what you are asking. Are you looking for software to allow NetWare applications to talk to a SQL Server running on Windows? The wording of your original question implied that you want SQL Server to run on the NetWare machine.
The question of why SQL Server doesn't support NetWare is best asked of Microsoft, but AFAIK SQL Server doesn't support any non-Windows OS.
As someone else said, SQL Server originally came from Sybase's SQL Server (now called Adaptive Server Enterprise), which supported NetWare at one time but dropped it a long time ago. Sybase's other RDBMS, SQL Anywhere, dropped NetWare as of version 11, but versions 9 and 10 are still supported on NW.
OK, now I think I understand. I was thinking "client" as in database client application, not the Novell client.
I don't think you'll need the Novell client on the Windows machine, for a couple of reasons:
If the client is trying to connect over TCP/IP, it doesn't matter whether or not the Windows machine has the Novell client installed
Windows shares aren't affected by the Novell client, though you need some kind of Novell client for the Windows machine to map NetWare volumes
If the Windows machine does need to map NetWare volumes, I have found in the past that the Client Service for NetWare service (which ships with Windows but isn't installed by default) is sufficient, and doesn't have all the overhead of the Novell client.
It sounds like your Windows SQL Server is in fact a second class citizen on your networks. (I imagine you are using SQL Authentication instead of AD based.) If you have to connect via IP rather than name, then your Windows boxes aren't participating in an Active Directory authentication + DNS setup like is the case in most "windows" networks verus the "netware" network that you are running into. Netware has it's own form of directory services that is independant of Microsoft.
If you want your Microsoft SQL Server to be a integral part of your network, then you need Microsoft Active Directory installed with integrated windows authentication and DNS services running on a Domain Controller. But, this would conflict with your directory services (if used) on your netware server.
If your Netware network is running just fine, then I wouldn't change it. Simply add the microsoft sql server's network name to your local DNS services and it won't appear like it's a second class citizen. You could install the netware client on the SQL machine but that would make most DBA's cringe. But, it would register the machine in Netware's directory.
SQL Server, although rooted in a Sybase/Unix/VMS background, is a native windows application. Apart from the compact edition (which runs on some Windows mobile platforms), SQL Server runs on Windows desktop and server operating systems.
More informaiton can be found at wikipedia.
Sorry to be prickly, but I'm not a noob: I know you can't install SQL Server on Linux. Do you guys have customers running Netware trying to connect to a SQL Server? That is what I am dealing with.
We have customers, mostly school systems, that use Netware as the "network OS" with many Windows workstations running the Netware client. Our app uses SQL Server which is usually installed on a Windows 2003 server, but the server is always a second class citizen on the network. Users often must use the IP address rather than machine name to connect the SQL Server.
#Will: Do your Novell customers have trouble accessing SQL Server on the Windows server? Can you install the Netware client on the Windows server to enable file sharing?
#Graeme: Thanks for helping me refine my question. My employer somehow has the impression that a Windows server is a second-class citizen on a NetWare network. Would installing the NetWare client on the Windows server make it easier for NetWare clients (with some form of Windows OS) connect to the SQL Server? Would installing the NetWare client on the Windows server allow the server to share directories and files like a Novell server?
#geoffcc: The app uses SQL Authentication to connect to SQL Server.
The core issue is how are you authenticating to the SQL database. If you have an Active Directory tree, and an eDirectory you can easily link the two via Novell Identity Manager, which will synchronize users, groups, etc (any object you care to map between the two systems) as well as passwords.
Thus the same object exists in both locations so each system can use it as much it needs too. The license for Identity Manager is included with the Open Enterprise Server license (OES can run on Netware or on SUSE Linux Enterprise Server (SLES)).
Then you could use the Active Directory integrated authentication.
Beyond that, your Netware server likely does not need to connect to the database directly. If it does, you will be writing or using an application that includes the database connectivity. At which point it becomes a question of is there a client for this OS or not.
#flipdoubt Well if you are using SQL Authentication, then you are using a SQL Client of some kind to connect to it, and the fact you have Novell in the picture is as unrelated as if you had Banyan Vines. (There you go! Now a search will show at least ONE reference to Banyan Vines!! Every good technology site needs at least one, and probably not more than one!)
As others have noted, what are you trying to do?
If they need to use the IP address of the SQL server to connect to it via a SQL client, then you have a DNS problem.
If you want to connect to the MS SQL server box to put a file on it, then that is somewhat unrelated to the SQL aspect of the issue. There again, DNS can solve your woes, if you register the name of the server (Say it is SQLSERV1) with the default DNS name (say acme.com) tacked onto the end of it, so that the IP Name sqlserv1.acme.com resolves to the IP Number you want it to point at.
Next comes the question of where are the user identities stored? You are using SQL Authentication, so that means you are creating accounts in SQL for each user.
The basic alternatives are to use Active Directory and have MS SQL server use those identities. If you are in a non-AD shop, you can investigate Novell Identity Manager product which has a JDBC driver that can do a fair bit, One thing it can do is synchronize users from eDirectory to be SQL Server users. (Or to Active Directory, Lotus Notes, most LDAP directories, AS400's, mainframes, NIS/NIS+ and many more systems).