I am planning some reports with quite a heavy load of calculations, which I thought is better to transfer to a custom .NET assembly loaded to Microsoft SQL Server. The companies who will use this will only use SQL Server Enterprise editions, so no problem with feature support.
The question is:
Is it actually a good idea?
I want to export this functionality because I want to be able to use features like:
Multi-threading (the number of threads will be the minimum between the processed entities, and the maximum number set in configuration file. I don't know any other upper limit I should specify.)
Unmanaged code (C++ libraries for stream processing)
Sometimes even COM Interop or shell commands, though this is less likely.
Will they work fine? Are there any limitations I should know about, in my case?
Everything you list is possible with some limitations. The Host Protection Attributes allow access to create threads, but prohibit access to Thread.Join etc. Read more about it on msdn
Now the question is "Should you do this"? I think the approach is not very sound as it will put a big processing load on your database server which will be very hard to scale if needed. I think a better approach is to add a Custom assembly to SQL Server Reporting Services and let the processing happen over there. If you run into scalability issues an additional reporting services machine can be added.
There are also no restrictions on methods & classes in assemblies loaded in Reporting Services.
Related
I've been running in circles looking for a way to deliver data from a proprietary flat file database (based on the ProvideX platform) to a client-thick web application that makes RESTful requests and expects JSON responses.
ProvideX and Sage MAS 90 provided an ODBC driver that works for pulling tables, but I can't think of a good way to connect the dots without needing to program a bunch of server-side code.
Before I go down the path of programming custom server-side middleware, does anyone have any bright ideas, (or obvious ideas that I have overlooked)?
I am not locked into any particular architecture at the moment because we are hashing out requirements for the web application, so any ideas would be helpful.
ProvideX/Sage provides a web services module, but I can't use it because my company has refused to invest in the software module and upgrade costs. Let's not let that be a distraction, however, because I am still looking for a way to use the ODBC driver in this question thread.
ODBC-ODBC Bridges exist but all the ones I know are commercial.
Back in the MSSQL 2000 timeline, there was an IIS integration layer that allowed HTTP GET commands to make select statements, and there were other SqlXml niceties that worked (not that fast or well but they worked) out of the box. I gave a chance to expose database stuff fairly quickly.
What is the comparable technology for MSSQL 2008/2012? I saw slashDb (http://www.slashdb.com/) and it seems to do that, but I am trying to understand the other options out there. Just SQL Server crud and sproc access.
Thanks.
Yes, SlashDB does exactly that and more. Full disclosure: I am the founder and CEO.
Once SlashDB is installed you would use its web interface to connect it with your database. Depending which database login and database schema you use for that connection, you will have the tables and views from that schema turned into of URL endpoints.
Those URLs can be followed in the browser but they are also API endpoints in JSON, XML or CSV. It works for reading and writing (you can control that in user configuration).
In addition to that you can define a set of parameterized SQL queries. Each query is given a name and instantly becomes an API endpoint too.
In order to help you getting started easily SlashDB is available on AWS and Azure marketplaces, as a Docker container from DockerHub, pre-built virtual machines or as .rpm and .deb packages for installation directly on Linux.
For more technical info please visit: https://docs.slashdb.com
The nearest equivalent may be SOAP/HTTP endpoints, however Microsoft has deprecated them for various reasons and recommends WCF or ASP.NET instead. Although the simplest way to get a quick CRUD setup is probably to use a framework or ORM that generates it for you, like LINQ to SQL or whatever else suits your needs.
I would like to design a database application using Microsoft Access. Before I start there are some important features I want to make sure are available in Access.
In a multi-user environment can the database be accessed simultaneously by different users such that only individual records are locked/unlocked as necessary?
Does Access need to be "opened" or can a "front end" be designed so the user only sees menus, menu bars, tabs, data screens, etc?
Can the database design features be locked so the user cannot change any database features?
Thank you for your help.
AF
Yes, certain records can be locked.
For Example, if you work with an ADO Recordset:
recordset.Open Source, ActiveConnection, CursorType, LockType, Options
LockType defines the locking-mechanism used for the selected Query Source.
More Information on that: http://msdn.microsoft.com/en-us/library/ms675544%28v=vs.85%29.aspx
Usually you split your Database into an frontend and backend. The back-end only contains only the tables, the rest goes in to the frontend. The backend tables are then linked to the frontend. Here is a link explaining how to do that: http://www.fmsinc.com/MicrosoftAccess/DatabaseSplitter/
In the frontend file can be compiled, so that the frontend users cannot edit sources.
In response to the third of your initial questions please note that Microsoft Access offers the facility to convert an Access database to an executable file (having file extension "accde" where your forms, reports, code and macros are protected to a substantial extent. However the level of protection offered with regard to tables is low in that the same are directly accessible even in an accde. MS Access also offers the runtime version free of charge and does not restrict its deployment to as many users as you may require. It no longer offers user-level security. This feature has been replaced with an encrypted password feature. Thus you will have to insert your own design and code to impose access restrictions on different categories of users. Alternatively, to use the user level security feature, one has to develop his application in an earlier version of Access in which this feature was available and thereafter use a recent version to convert it. I am uncertain whether MS Access 2013 will entertain such a database but understand that MS 2010 will though it will not offer that feature when you create a new database inside it.
You can get SQL Express for free, it's a stripped down version of SQL Server. It will handle multiple user access significantly better and not come with the bloat/performance degredation issues that Access brings along.
There will be a slightly higher learning curve, but if you're looking to get your foot into the development world's door, you'll be much better off learning how to work with SQL Server than Access.
I have been investigating NServiceBus. I liked the idea of the pub-sub model, and that the only real coupling of the publisher and subscriber is the semantic of the message. Right now we use SQL replication to sync our data between the databases of different functional areas of our software. I hate this because our private schema is directly coupled to by the subscriber, and it makes it difficult to change on our side. I was thinking it would be great to replace this with NServiceBus publications, but the change seems a little drastic. What about just using something like SSIS? Can I accomplish the same decoupling using SSIS instead of NServiceBus?
SSIS is based on meta-data and therefore will still need to understand the inner schema of all your data sources and sinks. If the underlying meta-data for each source/sink changes your packages will have to change. You also are connecting via MS technologies and are thusly platform coupled. Since you are moving whole sets of data around it sounds like you may not be temporally coupled(system A has to wait for something to respond in system B). It's hard to tell without knowing more about the systems. Lastly SSIS must be aware of the physical locations of all the players in the exchange so you are spatially coupled as well.
In my opinion I don't think you can get to the same place as NSB without developing a lot of the NSB concepts into the packages. This would require using XML messages over the Sql Broker or something to that effect which has already been solved in NSB(see the NSB Contrib project on Github for the Sql Broker transport).
I'm investigating options for reporting on data in a custom salesforce application, since the built-in reporting tool is a bad joke.
The requirements are that the data needs to be accessible on-demand through the Salesforce website (likely through a web-tab, visualforce page, etc.), and must be able to do arbitrary joins of the tables, like ANY other relational database reporting tool. It is a huge plus to be able to give much of the specific report-design power to the end user, as well. Ideally it would play well with Oracle if an external DBMS is required, though this is not a strict requirement.
I hear good things about MS SQL Reporting Services, and there has been some talk around here about Crystal Reports. I'd be much obliged to get any thoughts and opinion on the various options and approaches out there.
It may be worth looking at tools similar to Teiid. What this does is provides a standard sql jdbc interface to any data source - including salesforce. With that in mind, that means you can then use any reporting tool. It also allows you to join across data sources etc.
I'm glad you call the current salesforce tool a joke! :)
As for reporting, we use Pentaho from the open source world, which is a very powerful tool, but does take some learning. Of course, the final decision wont just come down to functionality, but cost too, and this is where Pentaho is likely to win hands down. Pentaho plays very well with Oracle, and also MySQL too. (And many more dbs)
Finally you probably want to nail down your requirements a bit more. Do you need plain reporting, dashboards, more advanced analysis? Data mining? How far do you need to go..