Is there any sort of non-SQL API for talking to SQL Server? I'm curious if there is a more direct way to retrieve table or view data.
(I don't have a problem with SQL, just curious if any of the layer between the SQL parser and the underlying data store is exposed.)
No, not as part of the actual SQL Server product, you'd have to install some other application to present/map the data in the manner you're after. But that would probably have to use SQL to get the data itself, defeating your intention.
Your best bet for retrieving data is SQL, but if you're interested in the plumbing you could look at TDS: http://en.wikipedia.org/wiki/Tabular_Data_Stream
You could look at the FreeTDS library: http://www.freetds.org/faq.html
Related
I want to use mysql proxy for processing queries trying to execute. I want to make this process available for all databases like mysql, ms sql server, oracle and ...
is it possible to use mysql proxy as base engine and connect these database from that? if no, is it possible to do this by making some little changes to mysql proxy source code?
You could use the standard external stored procedure support in the DBMS, but it would be difficult to map arbitrary queries to something meaningful.
Your are likely to be more successful implementing a lightweight parser as described in MySQL Client/Server Protocol and What communication protocol uses MySQL?.
Your preference that this can be done with 'some little changes' is likely not to be realistic. Expect a major job of the scale of ODBC to implement a generic SQL dialect translator.
I found that i have to use other exisiting proxies and change them in order to get what I need
I will have a Postgres database in production but want to use MS SQL (whatever edition) for reporting. So, I would like to have replication set up where MS SQL subscribes from postgres. Is this possible?
All heterogeneous replication scenarios are deprecated by Microsoft, and they now recommend building solutions using SSIS and CDC instead.
We load data from PostgreSQL into our SQL Server reporting database using SSIS and it works well, although we had to use a commercial OLE DB provider because of limitations (at that time) in the open-source one.
Actually copying the data is usually the easy part; most of the work comes in gathering requirements, understanding the data, transforming it, implementing logging and error handling etc. SSIS can do some things for you right away (e.g. logging) but my general advice would be to use it primarily as a workflow tool and for simple data copying with minimal transformation logic (e.g. data type conversion). If something seems seems too difficult or clumsy in SSIS then you can put it into a stored procedure or script and call that from SSIS instead.
I've been using and following PostgreSQL for several years and not aware of such a solution. If one exists, I'm concerned that might be complex or fragile. I would recommend regular export/imports via cron. In the between the export and import, you would need to take care of the translation step of the formats.
If you reporting actually happens in MS Excel or MS Access, I recommend looking into connecting them directly to PostgreSQL via ODBC.
I'm currently doing a business intelligence research about connecting Microsoft SQL Server to a nosql database.
My target is to import data from a nosql table to a relational DWH based on SQL Server.
I found the following approaches:
Microsoft Hadoop Connector
Hadoop Cloudera
Building an individual script and create an xml and include it via Integration Services (not really satisfying)
If somebody did something like this before or knows some kind of "best practices". It doesn't matter wich NoSQL system is used
NoSQL, by "definition", does not have a standard structure. So, depending on what NoSQL backend you are trying to import from, you will need some custom code to translate that into whatever structured format your data warehouse expects.
Your code does not have to generate XML; it could directly use a database connection (e.g., JDBC, if you are using Java) to make SQL queries to insert the data.
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 don't know between ADO, DAO and DLookUps and such. Does anyone know?
I find that the application bottleneck is usually the actual SELECT/INSERT/UPDATE on the DB and not how the application calls it. if you are worrying about speed make sure you have well designed tables and indexes.
Regarding DAO vs ADO, I'm not sure about a difference in performance but there is a difference in available functionality.
There is a microsoft article showing the differences in a nice table. Choosing ADO or DAO.
It also states:
"In particular, ADO is a good choice if you are developing an Access database solution that will later be upgraded to SQL Server — you can write your ADO code to minimize the number of changes that will be required to work against a SQL Server database. In addition, ADO is a good choice for developing new data access components that work with SQL Server, multidimensional data, and Web applications."
Seems like ADO might be the way to go.
I don't know anything about DLookUps though.