Our application from a vendor is using SQL Server 2008 R2 as its database on the backend. Although rarely, but sometimes an issue comes up that we think is related to their database (for example a performance issue etc.). We cannot modify their propriety database but want to detect transactions going into that proprietary(vendor) database and react accordingly. Question: How can we achieve the above in their propriety SQL Server database?
UPDATE
I probably did not phrase the above question well. So, I'm writing this update. What I mean is the following: In a similar scenario for another application that uses propriety Oracle database in its backend we use Oracle’s LogMiner utility to detect transactions going into that proprietary(vendor) database and react accordingly.
You can't. You can talk to the vendor and see if they'll give you an admin login/password into the database directly, but they aren't likely to want to for fear that you will break something and then blame them for it. Your best bet is to file a bug report with the vendor and pressure them to fix the underlying problem.
Related
I have an ERP system which I maintain with a team of people. However lately we seem to be loosing track of who's changing what and we need a solution to be able to control these changes. We are looking into the enterprise version of GIT as all our software development and web development would work perfectly with it. Not to mention I have some experience with GIT already.
The problem is we need the version control to extend to our SQL Server which we use SQL Server Management Studio to maintain. We have thousands of tables in 6 main databases which have a lot of stored procedures which are being changed.
It's not so much we want to control the source as in, permissions and refuse changes by people. It's more, we need a way of tracking changes and attaching explanations to help our future selves.
Does anyone know any solid solutions which would fit our purpose?
Assume the cost isn't a main factor.
I was using RedGate tool. It can integrate with Git.
RedGate SQL Source Control
I have been asking myself this question once. So I've found following solution which I can suggest you to use.
It is a SQL Server Data Tools that solves the problem.
The tools include SQL server database project for visual studio. This project will store your database structure. You can just add it to you solution. Then run a schema comparison with your database to take a snapshot of your current database state. You can choose what objects to compare. Since this moment your have all your changes being tracked by your VCS. Every change is documented now.
You can make changes in DB project and when you are done just run schema comparison, get the update script and apply those changes to your SQL server database. It is really not that hard to work with your schema from DB project as it provides intellisense, syntax validation. Also it is possible to write and execute SQL queries against you database.
My question is this: Are there alternatives to ODBC that would allow us to connect our SQL Server to MS Access?
Here's the situation: My company works with a proprietary, SQL database (ProVenue) that up and decided to "no longer support ODBC" to MS Access, our front-end tool, without telling us.
We are currently migrating away from ProVenue, but in the meantime , we're stuck with a vendor, which "no longer supports" our ODBC connection(s). The vendor also has no incentive to help since we're leaving in several months.
I've devised a workaround where I manually export the ProVenue tables (ASCII), proof (yes, the export utiliy pulls unreliably), convert and upload on a daily basis into Access. That said, it is unreasonably time consuming given the number of tables. This work-around could be a full-time job.
Do you know of any alternatives?
Do NOT consider using ADP. It has been dropped from Access 2013 and hence is a technology with no future.
From what you're saying, you don't "own" your own MSSQL database - you're simply connecting to an instance that the provider manages, correct? I would guess that they've disabled ODBC connections to MSSQL because they don't like the load placed on their servers and/or that they've decided they want to change some underlying structures and don't want to have to cope with anybody whining about those changes.
That said, do they allow direct MSSQL connections? Via SQL Management Studio, for example? If so, you should be able to define an export & import process which is less buggy than theirs, and simply re-point your Access database to the local copy of data. True, this would still require some (possibly automated) import process, so you'd be out of synch with the server, but it'd give you the solution.
You might try connecting an .adp file to the server, to see if they'll still let you access things in that manner. That would possibly require significant modifications to your Access solution, but would also be a bit easier on their servers than linked tables via ODBC.
You could have a look at Access Data Projects (ADP) which are tied directly to one SQL Server database. I don't think they use ODBC at all, but they have their own limitations, and of course, aren't available in older Access versions.
I have a vb.net project that uses a SQLite database. I do this by using dataset/table adapters. The client is happy and all works well. However I have just heard that they plan on providing this product to another customer that wishes to use their SQL Server database. So I am writing this post so I can mentally prepare for this before I begin. I am not a database pro and have really enjoyed the simplicity of setting up and managing an SQLite database.
So any ideas on the easiest way to support SQL Server as well? I am happy to run them parallel to each other. Can I just make a separate service / middleware that syncs the SQLite database to the SQL Server on a timer and does not care about what the main app is up to?
Any pointers are appreciated.
Synchronizing two databases is possible, if rather complex. You need some mechanism to find out which records have changed, and if it is possible to have new changes in both databases, you also have to resolve conflicts.
A timer-based approach doesn't sound efficient: in most cases, the timer doesn't have anything to do; and after some data change, there is some amount time where the databases are not synchronized.
Can't you just replace SQLite with MS SQL Server?
I.e., have some configuration settings that determines whether your program's data lies in SQLite or on a server?
Assuming that an SQL Server database with the required structure already exist, this would, in theory, need nothing more than a changed connection string, and supplying some user name/password (if the server isn't configured to automatically use Windows logins).
There shouldn't be any big differences in the SQL dialects used. You have, of course, to test all your queries.
Is there seriously no way of using a shared access non-server driven database file format without having to use an SQL Server? The Entity Framework is great, and it's not until I've completely finished designing my database model, getting SQL Server Compact Edition 4.0 to work with Visual Studio that I find out that it basically cannot be run off a network drive and be used by multiple users. I appreciate I should have done some research!
The only other way as far as I can tell is to have to set up an SQL server, something which I doubt I would be able to do. I'm searching for possible ways to use it with Access databases (which can be shared on a network drive) but this seems either difficult or impossible.
Would I have to go back to typed DataSets or even manually coding the SQL code?
Another alternative is to try using SQL
Install SQL Server express. Access is not supported by EF at all and my experience with file based databases (Access, SQL Server CE) is mostly:
If you need some very small mostly readonly data to persist in database you can use them (good for code tables but in the same time such data can be simply stored in XML).
If you expect some concurrent traffic and often writing into DB + larger data sets their performance and usability drops quickly. They are mostly useful for local storage for single user.
I'm not sure how this relates for example to SQLite. To generate database from model for SQLite you need special T4 template (using correct SQL syntax).
Have you tried SQLite? It has a SQL provider, and as far as I know EF supports any provider. Since it's file-based, that might be a plausible solution. It's also free.
I have been working on VB6 database desktop programming, but now a client is asking for a
simple web interface (some inserts into SQL Server db used by a desktop application).
The question is: Which approach is better?
1)creating asp.net project, connected directly to the SQL Server database;
2)creating separate (simple) mysql database managed by php and synchronization (in 15 minutes for example)
Thanks.
Personally since you already have the SQL Server database, I see no reason whatsoever to add the complexity of another database and then synchonization. The first alternative is simpler to create and can be secure if you design it correctly. The issue about hosting is irrelevant since you are going to your own database that already exists, so is the issue about cost since the databse is already there. Further since you are already supporting SQL Server, you may be able to reuse some code rather than write new code (mysql's version of SQL is not the same as SQl Server's version). Synching the two databases may be more complex than you think (differnt data types, etc.) and the data in the real database is not real-time whereas with the first alternative it is.
I'd prefer the separate database approach.
It's more secure.
PHP/Mysql hosting is widespread
You can pretty much achieve anything with the technologies available, it just depends on your skill and productivity with specific technologies and the availability of online help. Plus Microsoft stuff you tend to have to pay for whereas PHP/MySQL is totally free.