I am trying to make life a little easier for several coworkers and of course ME!. We need to update a database that controls our invoicing function. This database is housed in SQL Server 2008 R2. I need to provide users with a way (based on their function) to enter information affecting the invoice. For example, John has customer interaction and sends them a pdf of a document on Monday. We need to capture that John sent Customer A a pdf on Monday and it was associated with Project 123. Simultaneously, Ann is color correcting a piece for Customer A but on Project 126. I have over 50 people working in various areas who may or may not need to enter information. My hope is to make the application generic enough that the user simply selects from drop downs tied back to the original database.
The majority of the users (80%) use Mac OS. I have donwloaded XCode and I was hoping to use this to create the application that will update the backend database.
I am new to creating this type of application. I have done this with VB and VBA but do not have access to those tools here. So if there is another tact that I should take, I am more than willing to rethink my approach.
Key points are that I need to draw information from and update a SQL 2008 database. Second, I cannot use something like Excel as a front end, since I will have multiple users accessing information simultaneously.
You're unlikely to find many examples of connecting a Mac app directly to SQL Server, because that's a rare combination. Macs, unlike Windows PCs, aren't often used in an enterprise setting, so the software ecosystem to support enterprise development is much weaker.
If you're feeling brave, there are vendors out there that sell ODBC drivers for Mac OS X, some of which connect to SQL Server. So your problem becomes finding Mac ODBC examples, which is IMHO an easier problem. Google "mac os x odbc drivers". I have not tried any of them, so I can't speak to their quality.
This is going to be a lot of work, especially since you're new to the platform. You might want to consider exposing the database as an OData source (the name of the server-side technology is "WCF Data Services"). There are OData client-side librarires for the Mac. Google "mac os x odata". This approach completely bypasses the business of ODBC drivers, at the cost of some server-side development.
Related
I have a MacBook Pro and want to learn more about sql, I understand I cannot run sql from a Mac, what should I install VMware, linux, windows 10? Can someone walk me through this
SQL is just domain specific language (primarily) for relational databases. What you need to decide is what RDBMS, which in turn implements SQL, you would like to use.[1] Standalone implementations like SQLite definitely run on the Mac (many of Apple's own applications like Mail use it as their database.) For the more complex client/server RDBMS systems (i.e. Oracle, SQL Server, MySQL/MariaDB, etc.) you will at least need to install client-side drivers (often in the form of ODBC, JDBC or native drivers) and then either connect to an existing[1] database or install your own database server.
Since it sounds like you're just getting started, I'd highly recommend starting with a standalone database such as SQLite which you should be able to get to by opening a terminal window and typing 'sqlite3' at the prompt. This will allow you to jump right in and focus on learning SQL itself rather than dealing with getting a full-blown client/server database server up and running. (move on to that later if you find it needed/interesting/useful to you)
[1] unless you need to use an existing database, at work for example, in which case you'll need to find out the various details about the server and database in order to connect to it. In this case, you'll need to find a point of contact (often a DBA) to provide this information.
I'm not sure if this is the right place to ask this question. If not, please direct me to the right place.
We used to have an application that was created using VB and Microsoft Access. It was an application to score calls from Agents and would then run a few calculations and grade those agents based on a few algorithms.
We replicated all that Access data onto SQL but for some reason, we were just not able to connect the VB application to the SQL Database instead. The application was also outdated and we needed a change.
Can anyone suggest software/framework that can be used to create a new application with an ability to connect to a SQL database?
EDIT: We have a Microsoft Office 365 subscription. I was thinking of using PowerApps. I've never used it before. Does anyone think this could help serve my purpose?
I have extensive experience of using PowerApps to create applications connected to SQL Server (in my case Azure SQL Database), and am mostly satisfied.
There are some constraints, but not major. Please see these posts for some further information.
I would suggest PowerApps if you have Office365.
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 am not very familiar with Access database till now i was only programming to SQL Server but now it's time to do so. I am building WinForms application which will be using Access database and i have some question related to that point if you don't mind. My application will be used by multiple users and there will be one access databsae. My questions as below:
Is there any problem with accessing access database in same time by many users or only one user can be connected?
If i develop my program to use access 2016 and some of my users will have diffrent windows version and also diffrent access version
will it works?
Should i know something else? :)
If your client want to have a file based database and this is a project constraint , MS Access is the best choice. If you want a more detailed advice, please let me know how many users will perform Read/Write or Read transactions, the size of the database and if the application will run in client-server mode in a LAN/WAN, Cloud or Remote Desktop environment.
Back to your questions:
Depending on these conditions you may range from 10 to 20/25 users. Remember that you can always try with MS Access and later upgrade to a MS SQL database in a couple of hours.
If your front-end application can link to a 2016 Access database, it will do that without installing MS Access to the clients that will run your App, i.e. the vb.net compiled App will install all needed drivers. If you develop your App within MS Access 2016 (Access Form and reports, some VBA) you can run it with the free runtime version of MS Access, but this only when no older version of Access is installed on the running workstation.
Please check with your client the real reasons for a file-based database...
To answer the questions as asked:
You might run into an issue with this, as access was really designed as a personal use database. Having anything more than a small handful of users hitting against it at once will in fact cause problems, as it's not really well designed for that purpose...
This should in theory be fine, as the application itself is interfacing with the database, not the end user...
It seems like you're taking a step backwards using access for this, and SQL might very well be better suited for this purpose. This isn't me trying to just bash access either, this comes from personal experience. Going with this sort of design is likely to cause you more headaches than good.
I'm doing a project with vb.net (smart device) on visual studio 2008 and I need to connect to a database on the device itself (I do not have a physical device to test, only emulation). How should I go about doing it? I would like the database to be in the device on start up.
I've read on the internet that you have to make a reference to System.Data.SqlServerCe but the documents are, in my opinion, vague. So, I'm pretty lost here.
So there are two questions here:
How do I deploy my database so it's there when my app starts?
How do I access that database from my app?
Both are straightforward.
A1. You have a couple options. First, understand that SQLCE databases are a single file, typically with an SDF extension. You can either package it with your app for deployment, so you know it will be there on first run, or your app can check for its existence on startup and crete the file if it's not there. If you need to populate the initial database with data (lookups, etc) then option 1 is probably better. As long as you deploy/crete the database in a persistent storage location (and under WinMo/Pocket PC that's pretty much anywhere), it will always be there when your app starts up.
A2 You are correct that you need to add a reference to System.Data.SqlServerCe, which is again straightforward. Just add a reference in your smart device project:
Once you've done that, you use the SqlServerCe namespace objects to create the database, tables, indexes, etc, insert and query data, and all of that good stuff. Tutorials 2 and 3 on MSDN here are a really good start and they have VB.NET examples. The nice thing is that most desktop examples for VB.NET accessing a SQLCE database will work as-is on the device, and the things that don't work are usually in the presentation of the data, not the actual database access code itself.