I'm working on a desktop app that was developed about 5 years ago using C# and mssql server 2000.
This app uses OPENROWSET to load some xls files, and it worked just fine til the institution in where I work upgraded databases (to something like msserver 2019 or sort of), and OPENTOWSET stop working.
Despite knowing there's plentiful of procedures and recipes to fix this issue (which I cannot apply coz database runs on server), my company's DBA is telling me the only way to fix such problem is to give admin-privileges to the app-user, and he cannot do that because of safety rules - dropping the problem to me. Now I have to replace OPENROWSET with something else.
So the question is: is that true?
There's no way for a skilled DBA to make OPENROWSET work on a remote DB with regular/non-admin user, fixing those errors about permissions and linked servers?
Is OPENROWSET "mature-or-safe-enough" to make it run on nowadays production servers?
It looks like you are attempting to open excel files from within your database. In which case, the default setup would not allow this:
https://learn.microsoft.com/en-us/sql/t-sql/functions/openrowset-transact-sql?view=sql-server-ver15#remarks
OPENROWSET can be used to access remote data from OLE DB data sources
only when the DisallowAdhocAccess registry option is explicitly set to
0 for the specified provider, and the Ad Hoc Distributed Queries
advanced configuration option is enabled. When these options are not
set, the default behavior does not allow for ad hoc access.
When accessing remote OLE DB data sources, the login identity of
trusted connections is not automatically delegated from the server on
which the client is connected to the server that is being queried.
Authentication delegation must be configured.
It sounds like this may possibly have been configured way back in the past for previous databases, but the DBA who now sees this regards it as a bit of a security problem. Whether or not he is right depends very much on how you use this, but it does sound like something that would be better avoided.
It may be better to load the excel files in your C# application and then send the BULK data to sql server to just save.
Related
We are in the process of migrating an old VFP application into a .NET WPF application with SQL server.
During the process we still need to read/write to the DBF files to keep our business working properly.
To do this, we use the standard OLEDB adapter that is available. However, our sysadmin is asking if we have an alternative way to access the DBF files.
Having each user connect to the files is not the best option from a network/security perspective. Specially when connecting from home through a VPN.
I've already tried to move the connection to a single server by exposing the data through an API. But that was slowing down the application too much. In some situations we synchronise the data through background jobs (Hangfire implementation). But this can be time consuming to implement.
Has anybody used any other techniques to do something similar while migrating a VFP application?
OLEDB is still the best option. Within the application, you could impersonate a specific user that has access to files.
Also Sybase Advantage Server can connect and work with VFP data files. Local mode is (was) for free and server mode paid. You might try checking that too.
Locate data on single PC as server. Access via RDP - kludges available to support multiple connections. Increase security if needed by connecting over VPN - then RDP.
I developed a Winforms application with SQL Server 2008 R2 database for one my friends.
When I deployed & installed it on my friend's PC; software clearly shows database file. If he open that file in SQL Server, then he can able to watch my SQL queries, tbl structures etc.
I just want to hide all this from my clients.
How can I do this?
I search some of software on Internet. When I installed it on my PC; it not showing me any database file. How they do it?
Please help me.
If your application and database are both deployed on your friend's PC, there's almost nothing you can do to truly block him/her from getting to your database.
There is no feature in SQL Server that blocks schema view from an authorized user (e.g. admin) and if you own the machine, you can present yourself as admin to SQL Server in multiple ways even if you were not originally added to the admin role or given SA account access. You can setup hurdles like putting everything in stored procedures then encrypting the SP but it's just a small hurdle, not a wall.
This is not unique to SQL Server, the same issues apply to pretty much any RDBMS in the market. If you own the box, it's not hard to get to the DB contents. Software vendors have been trying do this for decades and most just give up and protect their IP legally instead. That's no consolation for you but it is reality.
If using a service like Azure is viable, you can host your app in Azure and the database can be Azure SQL DB or a regular SQL Server in a VM. I'd recommend the former if the feature set and surface area work for you; it's not identical to the SQL Server box product you're accustomed to. However, it is far less work for you to manage and secure. With the app also in Azure, your friend and clients will access via a browser and never have direct access to the database. Even if the app is installed locally on your friend's or clients' machines, it's easy to design the app such that they can only access data and nothing else.
I am currently working on a web app that will only be used internally. Part of the application requires employee information that is currently stored in our Active Directory. I have a sql server database already set up that I was going to store the info in but I'm not sure if it's needed. I can query the AD anytime to get the info I need so is it necessary to store it a second time in sql server? Will there be any significant performance issues if I am running occasional queries against AD vs. sql server? It's probably simpler to store everything in my sql database but I wanted to get some other input/advice as I have never worked much with active directory. (Also, this is not a data/network heavy app - less than 25 people will be using it)
Honest disclosure - I also don't have substantial AD experience.
If you duplicate the information from AD into SQL server, then you face the problem of detecting when it changes and updating the SQL copy. Your SQL copy will, somehow, lag or differ from the authoritative information in AD and your application will become known as inaccurate. Caching and ensuring cache accuracy is a very hard problem. Why take it on if you don't need to.
For light usage, I think an AD domain would handle it fine. If I understand it correctly, the domain controllers are load balanced across several servers. It does this for authentication, but I'm not sure about queries.
A Directory is an entity built to be simply interogated using LDAP. The main objective of a Directory is to centralize users informations just in order to avoid duplication in multiple databases.
So the answer is SURE use your Directory and interrogate it using LDAP (via ADSI in your case).
You need to duplicate entries in a database if you begin to plan frequent updates on user datas.
I am currently learning about EF and have come into a scenario where the data should be used in both an online and offline mode.
It is assumed that the user will have to use the system first while connected to obtain the data used offline.
I thought about serializing the queries but IQueryable/ObjectQuery are not marked as serializable.
How would I go about being able to store results from a few queries locally and then restoring them in offline mode so the use can continue to use the app? I could spend days researching this but I hope somebody can point me in the right direction.
EDIT
It is worth noting that the master SQL Server instance is a shared server that has very minimal features installed. Replication for example, is not installed.
Assuming you are using SQL Server, you vcould take a look at SQL server compact.
http://msdn.microsoft.com/en-us/data/ff687142.aspx
You could copy data from your main DB into a locally stored CE database then switch to this for offline.
I'm going to develop a POS system for medium scale company
and the requirement for me is to make all data on time for all of their branches
while in my mind, move the server from local to web would solve this problem
but, i never done any online server for window application
may i know what is the best option for use as secure database ?
such as SQL can handle this well ?
i tried to google but all of the result return is not what i want
may i know what will you do when you facing this problem ?
my knowledge on coding is just VB and CS
also SQL for database
i would like to learn new if there is better option
i hope it is impossible to access by anonymous and it is store secure at back-end only
What you probably want to do is create a series of services exposed on the internet and accessed by your application. All database access would be mediated by these services. For security you would probably want to build them in WCF and expose them through IIS. Then your Windows application would just call these services for most of its processing.
If you design it properly you could also have it work with a local database as well so that it could work in a disconnected manner if, for example, your servers go down.
Typically you don't move the server off of the site premises.
The problem is that they will go completely down in the event your remote server is inaccessible. Things that can cause this are internet service interruption (pretty common), remote server overloaded (common enough), basically anything that can stop the traffic between the store location and your remove server will bring them to their knees. The first time this happens they'll scream. The second time and they'll want your head due to the lost sales.
Instead, leave a sql server at each location. Set up a master sql server somewhere. Then set up a VPN connection between the stores and this central office. Finally, have the store sql boxes do merge replication with the central office. Incidentally, don't use the built in replication, but an off the shelf product which specializes in replicating sql server. The built in one can be difficult to learn.
In the event their internet connection goes dark the individual stores will still be able to function. It will also remain performant as all of the desktop app traffic is purely to the local sql box.
Solving replication errors is much easier than dealing with a flaky ISP.
I would recommend you to check Viravis Platform out.
It is an application platform that also can be used just as an online database for any .NET client with the provided SDK. It has its own generic windows and web clients and some custom web solutions for some specific applications.
You may be using it as a complete solution or as a secure online database backend.