I'm attempting to fix some problems with some old VB6 code for a client, and the previous programmer used Activex Data Object 2.7 stored procedures. After a recent computer failure and reimage, none of the buttons that use stored procedures in the application currently work.
So, my question is where can these procedures be stored?
Thanks
Stored procedure are on the database. Unless the database was on the local machine, there are only a few things of which I can think that could have been broken/reset by a re-image.
These are all used to remap computer name references.
HOSTS
DSN
SQL Aliases
Related
Does the DBMS save the compiled queries from prepared statements in JDBC, in the form of stored procedures on the DBMS server? I thought that prepared statement isn't a concept in DBMS but in JDBC, so I was wondering how it is implemented on DBMS server side.
My question comes from Why do Parameterized queries allow for moving user data out of string to be interpreted?
I read DIfference Between Stored Procedures and Prepared Statements..?, but don't find my answer.
Thanks.
I am interested in PostgreSQL, MySQL, or SQL server in order.
No, prepared statements are not implemented as stored procedures in any RDBMS.
Prepared statements are parsed and saved on the server-side so they can be executed multiple times with different parameter values, but they are not saved in the form of a stored procedure. They are saved in some implementation-dependent manner. For example, as some kind of in-memory object, totally internal to the code of the database server. These are not callable like a stored procedure.
Re your comment:
Consider MySQL for example.
MySQL in the very early days did not support prepared statements, so the MySQL JDBC driver has an option to "emulate" prepared statements. The idea of emulation mode is that the SQL query string is saved in the JDBC client when you create a PreparedStatement. The SQL is not yet sent to the database server. Then when you bind parameters and call execute(), it copies the parameter values into the SQL query and sends the final result.
I don't know whether a similar feature exists in other brands of JDBC driver.
I have an application in my company. I want to convert it from BDE to ADO Connection.
I searched almost everywhere, I did not find any good answer.
The AIM IS
Convert that BDE connection to ADO connection but we need to use TQuery component to fetch data from database.
So, it will look like we are using BDE but internally it uses ADO Connection.
So, please answer this question you cant imagine, how thankful i will be.
... if somehow we can set the database Alias to ADO connection ...
Just take a look at the source code of Delphi's BDE and ADO support (in e.g. DBTables.Pas and ADOInt.Pas + ADODB.Pas and you will soon see that they are as different as chalk and cheese.
You have no hope of e.g. using a TAdoConnection via the BDE from a Delphi app.
What you could do is do move your data to an ADO database (e.g. MS Sql Server) and then create a) a System DSN to connect to the ADO db via ODBC and then b) set up a BDE Alias that uses the BDE alias and c) change your existing BDE app to use the new alias instead of the one it currently uses. That way, you can continue using your existing app to access the ADO version of the data via TTable, TQuery etc and develop a parallel TAdo-component based equivalent at your leisure.
You could easily try this out using the traditional Delphi MastApp or "Fish Facts" demo application and data. Getting your existing BDE app to access an ADO-compatible copy of your data via an ODBC alias should not be more than a day's work even if you have never done it before. Actually converting your BDE app to ADO would likely take rather longer, though.
There are countless examples of different ways of copying BDE (e.g. Paradox) data to ADO data on the internet. Try looking at a few.
I am new to stored procedures, informix, and UCCX. I am working on a project to consolidate reporting into on BI tool, and it appears there are several UCCX stored procedures that could be great time savers for bringing the UCCX historical reporting into our BI tools. Can anyone offer tips on how to query stored procedures for informix via RazorSQL?
You are on the right track with your syntax. For example, I can call a different stored procedure by executing the following in RazorSQL:
execute procedure sp_agent_state_detail('2016-05-31 05:00:00','2016-05-31 05:59:59','0',null,'David Bowie',null,null)
The error you get is self-explanatory -- there is no calls_handled table. I suspect that the gettotalcalls() stored procedure is meant to be used in conjunction with some other code, perhaps another stored procedure, that creates that table.
Quick disclaimer: I'm a .Net developer and may not have provided all the information you need about the environment, but can get the information on request. We have COBOL programmers, but they have never done this.
We are converting a mainframe application with a DB2 database to a .Net MVC application with SQL database. There is one mainframe COBOL batch program that we would like to call from a COBOL stored procedure on the DB2. I've read this can be done, but I haven't found a good example of how to create a COBOL stored procedure that calls a COBOL program. The COBOL batch program takes about 5 input parameters, but does not return anything.
We already have a linked server that we are using to call native sql stored procedures on DB2 from a SQL server.
Edited for future reference below
We looked into two ways of solving our problem - creating a COBOL stored procedure that could be used by DB2-mainframe running on z/os where we'd copy/paste our COBOL from the CICS program and tweak it to run as a stored procedure (thus cutting out CICS completely) or using CICS to host a web service end point that can call to the CICS program we wanted to invoke, much like described on slide 21 of this PowerPoint.
We have decided to move forward with the second option because there is precedent for doing it that way already, so it's going to be the easier path for us.
Interesting question!
I was thinking of why not let your LUW DB2 stored procedure call a transaction manager which will execute your cobol program? This if you use a transaction manager in mainframe (which I assume you do!). If you are not familiar with this, just check your mainframe guys if you use transaction manager as CICS or IMS.
I have not done this, but it should work.
(alternative, call a http/webservice from db2 sp which will execute an ims transaction that executes your cobol program...)
I must add that I ve not tried any of above, I have´nt used db2 luw. But maybe the ideas are worth to mention here?
What is the difference between ADOTable and ClientDataSet?
Both components are capable of performing Batch Update, why add the extra overhead of having 2 additional components like ClientDataSet and DataSetProvider.
The main difference is that ClientDataSet can operate without a connection to external database. You can use it as in-memory table or load it's contents from file.
In combination with DataSetProvider it is frequently used to overcome limits of unidirectional datasets and as a cache.
A ClientDataSet is an in-memory dataset, which has a lot of usefull additional functionallities.
One big advantage compared to Interbase/Firebird tables and queries is, that you don't need to keep a transaction alive, e.g. as long as you display the data in a grid.
Have a look at this article:
A ClientDataSet in Every Database Application
Client dataset is a generic implementation that works regardless of the underlying db access library. It can work (through the provider) with any TCustomDataset descendant, be it a dbExpress dataset, a BDE one, an ADO one, or any of the many libraries available for Delphi to allow for direct database access using the native client (i.e. ODAC, Direct Oracle Access, ecc. ecc.)
It can also work in a multi-tier mode where the data access dataset and provider are in a remote server application and the TClientDataset is in the client application, allowing for "thin client" deployment which doesn't require database clients or data access library like ADO installed on the client (the required midas.dll code can be linked to the application when using recent versions of Delphi, anyway only the midas.dll is required otherwise).
On top of that it can be used as an in-memory table able to store data in a local file. It allows for the "briefcase" model also, where a thin client can still work when not connected to the database, and then "sync" when a connection becomes available. That's was more useful in the past, when wireless access was not common.
As you can see, TClientDataset offers a lot more of a TADODataset.
The most important difference I can think of is resolving update conflicts. In fact, TClientDataSet exposes the handy ReconcileErrorForm dialog, which wraps up the process of showing the user the old and new records and allows them to specify what action to take, while with TADOTable for instance, you're basically on your own.