I'm working with a third-party application that uses ODBC to connect to, and alter, a database. During certain failure modes, the end-results are not what I expect. To understand it better, I'd like some way of inspecting all the statements sent to the database. Is there a way to do this with ODBC?
I know with JDBC I could use http://www.p6spy.com/ to see all statements sent, for example when debugging hibernate. p6spy is a "proxy" driver that records commands sent and forwards them on to the real JDBC driver.
Another possibility might be a protocol sniffer that would capture statements over the wire. Although, I'm unsure if ODBC includes a standard wire protocol, or only specifieds the API.
Does anyone know of existing tools that would allow me to do either of these things? Alternatively, is there another approach I could take?
ODBC specifies how your program communicates with a local driver, not how the local driver communicates with the remote database. Your proxy driver idea is sound, you just need to find one.
Have you tried the tracing built into ODBC? In ODBC Data Source Administrator, there is a tracing tab. As I remember, the information captured is pretty verbose.
I think it is easier to read the logs on the SQL side, whatever the database. For example, turning on the monitor on SQL Server or viewing the logs in MySQL. It seems that using a sniffer would be more trouble than it is worth, but I guess it depends on the tools available. What RDBMS are you using?
Related
Is there any way to communicate with a socket using SQL language? (Why?) Assume that, I manually open SQL Server Management Studio and open a table and then insert a record manually (by manually I want to emphasize on the absence of any middleware in between). At this moment the business demands for signaling the inserted record to another context (as either notification, or report (i.e. grid view, etc)).
The solution that I have in mind is to write the inserted record to a file and using another application monitor the file for change (Emphasizing again that I don't wanna do this through a middleware at all) , but this method is not a standard way to achieve this requirement and it is more of a workaround.
Is there any standard way to signal changes using pure SQL Server syntax/features?
You can have a SQLCLR routine that calls out to "something", whenever a change happens. Where I work we ue that for real-time streaming of dats from SQL Server to RabbitMQ. In your case you would have to have a trigger on the table, which calls the routine.
In our case we always change data through stored procedures, so our procedures call the SQLCLR routine.
You could also use Service Broker and External Activation. In our case we chose not to do it as the performance was not good enough.
If you want, I have a blog-post about the SQL Server -> RabbitMQ integration using SQLCLR. Obviously it doesn't have to be Rabbit, we've also done it through socket connections etc. So if you're interested, the post is here.
Hope this helps!
Niels
I have a requirement to create a tablet application for use in restaurants. It will all be on a private internal network so security is not an issue. The question is which will cause the least network traffic? I can either connect directly to SQL using entity framework or I can connect to web services I create on the SQL server in IIS and the tablets communicate with that.
I guess to simplify it, does a standard SQL connection transfer more data than is necessary?
It's difficult to give a general rule, as network architecture plays into the answer quite heavily.
As a general guideline i would suggest to make web services or php "interfaces" on the server, it would give you a easier and more controllable data flow, besides you could handle transactions easier, as all of them would go thorugh one interface, all db accesses coming from one machine. It makes also debugging and errorhandling easier (log the interface and you see everything that's happening, so you don't ahve to check logs on devices) than if every client connects directly to the DB, gives you more control.
Just a general suggestion, a kind of web services/interface or whatsoever is always worth the investment, sooner or later you will go anyway this direction.
My humble oppinion
I am planning to make a VB.Net application that is hard coded to access an MS SQL database hosted remotely on a web server. Is there a way for someone using some packet sniffing (I think it is called) program on the client PC to somehow know what password was used to access the database? I don't need to know how it is done, I just need to know if it can be done so that I know if my approach is safe enough.
Thanks!
If you only care about protecting the login to the database, then you're OK, according to this MSDN article:
Credentials (in the login packet) that are transmitted when a client application connects to SQL Server are always encrypted.
But if you also care about protecting the data, then you should read the rest of the above MSDN link to learn about enabling SSL to protect the rest of the data stream.
Note also this older article which gives a caution on using ODBC connection (rather than the native tyep). I doubt you would be doing that, but just thought I'd mention it.
From a client machine, it is unlikely that your database information can be sniffed. However, if your application "leaks" information, it is possible for an outsider to get sensitive information about your database. For example, if you have the CustomErrors parameter set to "Off", and your database is inaccessible for any reason, users may see your database's address and can then proceed to attack it using brute force or known exploits. There are other ways you can leak sensitive information this is just one example.
In general, it is not ideal to have your database open to the internet -- it is generally advised that your database be behind one (or two in case of a DMZ) firewalls. If you can control this, you should move it somewhere more secure. Or else even without your application leaking its address, a port scanning "war dialer" will eventually find it and alert the "bad guys" to its existence.
My requirement is to retrieve data from a local SQL server and store that data in remote server. I would like to get the data from the local SQL Server and use that data in my application to proceed further.
Yes, see Create linked server with SQL command.
You can create the linked server either locally (I'd recommend that) or remotely
If you mean you want your remote server to execute queries on the local one then yes, but...
Setting this up is a fair bit of work and if I remember rightly needs a hefty amount of privileges on the remote server.
Might be easier to set up the linked server locally. NB assumes the account the local server is running as can reach the remote machine, and can access it.
I'd be a bit nervous about doing this, internally for fear of some admin type breaking it, if it's over the internet, then securing it will be a nightmare even if they allowed their server to be accessed directly..
You might find it easier to do it via the client, though that will dpend on how much data you want to synchronise, and then perhaps a briefcase approach might do the job better.
You can set up linked servers either via the GUI in SSMS, or via scripts. A couple of things to look out for though - first make sure you create a login account on each server that is mapped to the appropriate database on each server, with the least possible permissions. Then verify the mapping after you've set it up. Be aware that you are opening up the attack surface via this solution, so you may want to have your admin set up auditing too.
I've written a small (8-10 laptops) point-of-sale system running over a wireless network, as an HTA that reads from/writes to an Access MDB located on a network share.
I need to use ADO - GetString and the user roster are not available with DAO.
I also need to use DAO - the MDB cannot be compacted with ADO.
I know that:
1) If the database backend is not an Access MDB, I should use ADO.
2) If the backend is an MDB, but I want to upgrade to SQL Server at some point, I should use ADO.
3) Within an Access application, or any other VBA/VB application, I should use DAO, as ADO must go through a translation layer of the Jet OLE DB Provider, while DAO is more direct.
4) VBScript/JScript allows me to use either DAO or ADO.
The two-part question is as follows:
1) In this software environment (HTA/scripting), is it better to use ADO rather than DAO?
2) Does ADO offer any benefits because the HTA is reading/writing over a wireless network?
If the only reason you need DAO is to compact the database, you can use DAO for that, and use ADO for everything else. You are not limited to using only ADO or DAO.
The biggest benefit of using ADO is that it will be easier to move to SQL Server Express when the time comes. You should do that sooner rather than later, as SQL Server Express offers all of the benefits of MSAccess databases without the drawbacks. SQL Server Express is free, and it will easily handle the system size you are proposing.
Access databases corrupt easily in a multi-user environment, especially when a wireless network is involved. If you are worried about losing the benefits of working in MSAccess, you can still attach to SQL Server using linked tables, and work with your SQL Server Express database that way.
You can also use JRO to compact your MDB file. This will be included with any recent version of MDAC, installed by default on XP and later systems. No installation of Access is necessary.
To answer your specific questions:
1) I would opt for ADO just because it is more current, and the same API can be used in other kinds of scripting, like LDAP/ActiveDirectory access, reading file system folders, reading MAPI mail, and working with other types of semi-structured text files like fixed width text and CSV. It's not specifically better for the HTA programming environment, but its perhaps better for you to learn a more widely applicable API. I also thinks it's an easier API to work with, but I started with it and only later worked on some older DAO projects.
2) One possible benefit that ADO provides is that of disconnected recordsets, which may have an advantage or at least suggest some architectural alternatives in your wireless network setup. You open a recordset, then disconnect it, so you can still work with the data in memory, but not have to leave a database connection open. Then at a later time you can reconnect and update the database. Also, you can work in a fully disconnected style by managing tables as local XML or ADTG files.
You might shoehorn DAO into working from VBScript but that's an odd pairing. ADO makes the most sense in general.
Another advantage of ADO would be that it supports RDS over DCOM or HTTP. This can be used to overcome many of the limitations of Jet MDBs used via file sharing, such as the corruption unreliable networks and clients can lead to. It also cuts the amount of traffic over the network, improving performance. In addition it offers a middle tier in which business objects can "live" and all of this can be mediated using COM+ where applicable.
Of course you no longer have the option of using a simple P2P network and a file share to host the database. RDS needs a server to host the process and run the Jet engine, which no longer needs to run on each client system. This means you can use Jet stored procedures that run on the server, offloading more client processing and network traffic. While not as sophisticated as T-SQL or other alternatives, this ADO/Jet 4.0 OLE DB Provider exclusive technology offers tangible benefits that can't be had using DAO.
RDS can mask much of the process of using disconnected Recordsets, simplifying client code. It uses ADTG under the hood, which was developed and optimized for this very purpose.
However using RDS requires more infrastructure and expertise than a simple file share. You might as well look into a low-end version of SQL Server.
In general I'd recommend using the jetcomp.exe utility to compact and repair, over either DAO or JRO. It offers a number of advantages.
If you can afford to use a HTA application with Access instead of a more performant platform, I would say you should go with the easiest api for you. The bottleneck will never be the abstraction of db access in your case. Still, DAO is really old.