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 4 years ago.
Improve this question
I have a question: what is the best practice for migrating SQL Server stored procedures to Oracle?
Thanks.
Best is such a fun word.
But.
Oracle SQL Developer has built in translators, including one for SQL Server.
If you capture your data model using the Migration Projects feature, it will take your T-SQL procedures and convert/translate them to their PL/SQL equivalents.
Each translation will need to be verified/approved/tested, of course.
We see somewhere between 60-90% translation success rates, that is, translated procedures being 'good, out-of-the-box.' Results will vary based on the nature of your code.
I talk about migrations, with Sybase ASE as an example, in this whitepaper. The SQL Server scenario would be pretty much the same.
We also have an ad-hoc translator, but it won't take into account your data model.
I can attest from being involved in a large production legacy project, where substantial number of "automated" options had been evaluated - none of them worked, and almost nothing they did could even be used in the 'at least that' manner.
We wasted a lot of time trying to achieve automation, and then ended up converting everything by hand, which took much less when we involved a small team of coders, once they familiarized themselves with both syntax and optimisers.
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 1 year ago.
Improve this question
A legacy database project was built as SQL DataSets (80 DataTables with about 1000 Functions). Now we are modernizing the project to better technology. What concerns of choice to migrate to Linq2SQL or EF.
PS.
We don't want to re-write the entire database queries. I found a tool that helps generate Linq query from SQL query. Is there something similar to convert to EF?
LINQ to SQL is obsolete technology.
EF Core is modern way but has a lot of limitations in LINQ. So probably you will create new 100 functions when EF fail to translate your query.
Also consider look at https://github.com/linq2db/linq2db (disclaimer: I'm one of the creators).
You can scaffold any database via T4 template. Functions also will be imported.
Difference between EF Core and linq2db, that linq2db has no ChangeTracker but it uses LINQ for CRUD operations. And actually there are almost no limitations in creating fast and correct SQL.
For translating SQL to LINQ I know only one tool http://www.sqltolinq.com/ I've tried that many years ago and don't know current status.
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 2 years ago.
Improve this question
I'm hoping for some opinions on the best options for how to replicate, in real time, data from a production SQL Server database onto another SQL instance. This second instance would be for vendors who need to access some of the tables from the production database, but we would prefer that they not directly access our production instance.
I have some awareness of transactional replication and log shipping as possible solutions, but I would be interested in pros/cons of these approaches, or superior alternative solutions you may have tried.
I realize there are many topics already on Stack Overflow that discuss how to do this, but many that I found were older (technology's always changing), or focused on a very specific scenario.
For read-only access you can use AlwaysOn Availability Group feature introduced with SQL Server 2012
Documentation:
https://learn.microsoft.com/en-gb/sql/database-engine/availability-groups/windows/overview-of-always-on-availability-groups-sql-server?view=sql-server-ver15
https://learn.microsoft.com/en-gb/sql/database-engine/availability-groups/windows/configure-replication-for-always-on-availability-groups-sql-server?view=sql-server-ver15
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
is it better to put different parts of the app in seperate databases or in a single database file. for example putting forum tables in one database file and putting the blogs tables in another db ??
Separate databases probably don't make sense but, assuming SQL Server 2005 or later, I would encourage you to look into using schemas to logically separate these functional areas. See Buck Woody's article SQL Server Best Practices: User-Defined Schemas as a starting point.
is it better to put different parts of the app in seperate databases or in a single database file
Ah - waht exactly do you ask here? Is this about DATABASES or about DATABASE FILES - a database can have many filegroups which each can have many files.
Depends on size and IO requirements. I have seen databases with 28 groups of multiple files each, to optimize the IO bandwidth of the underlying SAN which was limiting every LUN (and that had multiple files per LUN) to 256 outstanding requests.
if you get into higher end requirements, that makes sense. Likely for you it does not, as your working indicates you dont really know databases, and so you wont work on a multi terabyte high end system ;)
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 2 years ago.
Improve this question
I have been given an assignment to get the feasibility for making a dll which takes some inputs such as database name (Mysql, access, sql, oracle etc.) and some more inputs to generate a query, and based on that the dll should return a recordset to the application.
Is it a good idea? If yes, then what inputs should I consider?
It's completely feasible, the issues arise when you encounter different SQL grammars - take a look at how Hibernate handles this with the use of Dialects.
The popular databases - Oracle, Sybase, MS SQL Server, MySQL - have slight differences in the SQL grammar they allow. Essentually the vendors have implemented and extended ANSI SQL in different ways.
The simplest case I can think of is when the way you assign pseudonyms to column names, some databases require this:
SELECT x AS y FROM some_table
while others require:
SELECT x y FROM some_table
There's many more such examples, but the bottom line is that when writing a query abstraction layer that works across all databases you need to abstract the concept of SQL generation so that it can be tailored to each database you are going to support (as I said, Hibernate does this by allowing you to specify a dialect specific to the database you are using).