Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
Our firm has a rather complex proprietary Access database system including 15 or so unique front end modules that all perform different tasks and a backend database for each of our clients. All of these front end modules and backend databases have many SQL queries, functions, macros, and VBA code. We are considering upgrading to SQL Server or an equivalent but I see several major pitfalls including the incompatibility with VBA and Access functions. Do you think it would make more sense to stay with Access and look into improving via 1. accde/mde or accdr/mdr 2. split databases and/or 3. merging/consolidating front end modules? Do some of you have experience with such an upgrade or have any other recommendations?
You should consider migrating tables to SQL Server and keeping the Access Front-end. SSMA For Access will move the data and replace the tables with ODBC linked tables for you.
Then, moving forward, you can continue to use Access or build applications using other tools.
It is assumed that you run front ends with linked tables to the back end accDB file.
You then can migrate that database to sql server, you migrate only the data part.
The access FE (front end) should work as before - about 99% of the code and forms will work as before, but some tweaks are often required. Given that SQL express is free, then it is great setup and will allow you to keep and preserve most of your existing software investment
However, on each workstation, you are placing a FE of the application on that workstation. You as a general rule can't allow multiple users into the same given FE - it is to be placed on each workstation.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 months ago.
Improve this question
I have a project that started simply enough with EF Core code first. I would create migrations and apply them with dotnet database update - I even have CI/CD apply the migrations to the prod DB once merged into the main branch.
Overtime however, the database complexity increased; views, stored procedures and functions were created to handle some cases that perform much better by remaining on SQL Server. The problem is the tables are now tracked in a SQL Server .NET Core project as well as in the the code first classes in the business layer of the app. With multiple developers, there is a path that a change made in one project is not reflected in the other. Policy and code reviews are the only gates we have.
What is the recommended approach here? I am currently of the opinion that since we have complex SQL objects such as views, stored procedures, function, etc... that we should treat the SQL Server Project as the source of truth and scaffold the EF classes but that fundamentally, the source of truth should be the SQL Server project and its changes should be applied to the database using Flyway or LiquidBase.
Yes. Code First design workflow is inappropriate when the database has significant SQL artifacts other than tables, or when the database design is performed by team members without .NET and EF expertise.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
I have few tables that I have to sync between 3 different RDBMS systems (PostgreSQL databases, a SQL Server and a Firebird Database).
Currently I simply connect to my Firebird database and pull the few relevant tables to my PostgreSQL database, but as databases change, new tables require querying and with the addition of a SQL Server database to the mix I feel this solution is ill fitting.
I've done some research on BI tools , but I still need to query data from this data source and show them inside a Windows Forms application.
PS: it's not a migration and I only need to query the data from these "satellite" databases
Using PostgreSQL as your hub, you can use Foreign Data Wrappers to reach out to the other two databases whenever a query wants their data. Then it will always be up to date, but performance might suffer compared to actually importing the data. For reaching SQL Server, you can use tds_fdw, and for firebird you can use firebird_fdw. I have never used either one of these, so this is just a starting point.
You could probably pick SQL Server as your hub and accomplish the same thing, it calls them "linked servers" rather than Foreign Data Wrappers, see for example.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I have written a project in C# which currently uses a SQLite database with 7 tables. Now I made a little mistake in selecting my database and since the application is going to be accessed by multiple users (~100) on a network the SQLite solution won't work because only one user can write at a time.
Now I want to switch to an Access (2010) database but my question is:
If I create the Access database with the same scheme as my SQLite database, do I have to change any of the SQL statements that I have written in my application? Or does this work interchangeable?
Also some side notes of why I am switching to an Access database instead of something like a SQL Server... Time does not allow this and costs neither.
Does anyone know what the impact will be if I'd simply replace the SQLite database with the Access database. And are there any differences in the SQL for these two for simple queries? I'm using things like 'INNER JOIN, IS NULL, SUM, COUNT'.
Thanks in advance!
are there any differences in the SQL for these two for simple queries?
For the simplest of queries, not really. For example, the specific language features you mentioned (INNER JOIN, IS NULL, SUM, COUNT) will likely work without modification, with the possible exception that Access SQL often requires parentheses when a statement contains multiple JOINs (example here).
Does anyone know what the impact will be if I'd simply replace the SQLite database with the Access database.
That is impossible to predict without a complete code review. You will really just have to try it and see what (if anything) breaks.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I am trying to create a log in page for my application. Since there are multiple users, my page will have the ability to store user names and password. I am using VS2012, being that I am new to programming, I am not sure if using Access or SQL Server. If I create the database to store the log in info, when I compile the program how would that affect the user who installs the program. Would the database "go with the program" when compiled?
I can also use Access to store the data, but I have the a similar issue. If the user's computer does not have Access installed on their PC, how would the table be accessed?
This is probably an entry level question, I have done some research on this but have not found much information.
If you store the login information in a Sql Server Database then you need to install the SqlServer on the customer PC and distribute your database file with your application. It is not an easy task to do in a setup project and probably this is a possible motive for Microsoft to develop the LocalDB version of Sql Server that is a little bit more easy to install.
In the case of Access you need to distribute the MDB file (your database) and (if you stay with the 2003 version) nothing else because all the required libraries are distributed together with the NET framework. In case you want to use the ACCDB file format then you need to install on the customer PC the Microsoft Access Database Engine. However in Access you could find problems with 32bit and 64bit version of the OS. It is advisable to use always the x86 as target platform.
There are also alternatives like SQLite and Sql Compact Edition.
In these days, I would use the cloud. Make your program a webapplication and use an SQL database. Then the program would be accessible in any location where there's access to an internet connection. This means that it can be used on Windows, Mac's, Linux, tablets, smartphones and even smart tv's (Not that anyone uses that).
There's good tutorials on how to do this for a webapplication from PHPacademy. See:
http://www.youtube.com/watch?v=9kyQGBABA38&list=PLE134D877783367C7
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
For an existing web application built on using Oracle database, what are the choices available in order to scale horizontally. Few thoughts are:
Have multiple databases and multiple application servers each connecting to a different database and a controller application with his own database whose role will be to decide which request to send to which server. Challenges involve moving existing data from one database to another as and when required in order to evenly distribute the load on multiple databases. Also keeping all the common data on all the database in sync with the controller database.
Move to NoSql
Any other?
Please suggest.
The standard approach to horizontally scaling an Oracle database is to use Oracle Real Application Clusters (RAC). RAC allows you to have a single database on a shared file system (i.e. a NAS or a SAN) that is mounted by multiple different instances running on multiple different database servers simultaneously. Oracle takes care of keeping the data in the caches of the various nodes in sync.
If you are using the enterprise edition of Oracle, RAC is an extra-cost option (you'd need to speak to your Oracle Sales rep to get a quote). RAC is included with the standard edition (though the number and size of machines you can have in a standard edition RAC cluster is limited).