| Oracle & Vb Connectivity [message #102224] |
Fri, 29 March 2002 20:13  |
Vikas Kale
Messages: 8
Registered: March 2002
|
Junior Member |
|
|
|
I am a beginer for Oracle and Visual Basic. I have oracle 8.1.7 loaded on my NT Server, I want to connect vb & oracle client on my node. How can I connect Oracle Client and Visual Basic for Node. What are the Software required to be loaded onto my Node.
|
|
|
|
| plz help:Starting Oracle Service from VBApplication? [message #102354 is a reply to message #102224] |
Tue, 07 May 2002 04:15  |
vipresh
Messages: 1
Registered: May 2002
|
Junior Member |
|
|
:we have a software developed Using Oracle and Vb6.0
But the problem is evry time before starting the application we have to start Oracle service manually
which has been created by us.
Is ther a way to start Oracle service from Vb
If yes plz help me as fast as possible.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: Oracle & Vb Connectivity [message #103230 is a reply to message #102667] |
Tue, 11 March 2003 01:14 |
pulkit sharma
Messages: 1
Registered: March 2003
|
Junior Member |
|
|
prepare a dsn in control panel
enter name and passwords etc
then click ok
now come to vb add ado control thru components and then
select its properties select ther dsn property and u will find ur dsn there then came to authenticartion part add usernanme and password then came to the recordsource part select the 2-adcmdtable now close the property window run the form u r now connectefd to ur oracle server
reply me if its work
|
|
|
|
|
|
|
|
|
|
| Re: Oracle & Vb Connectivity [message #103848 is a reply to message #102959] |
Thu, 08 April 2004 19:47 |
eilison
Messages: 22
Registered: August 2003
|
Junior Member |
|
|
sample code of VB-Oralce_ADO can be found in microsoft website, www.microsoft.com msdn.microsoft.com
similar sample code may also be found in oracle website, otn.oracle.com
but in my experience, stuff about this from microsoft are more comprehensive.
hope it helps
eilison
eilisonl@yahoo.com
|
|
|
|
| Re: Oracle & Vb Connectivity [message #103850 is a reply to message #102959] |
Thu, 08 April 2004 23:07 |
eilison
Messages: 22
Registered: August 2003
|
Junior Member |
|
|
OLE DB vs. ODBC
ODBC has been and remains a very important and successful data access standard. The ODBC technology and third-party market have matured to a point where ODBC is an ideal technology for accessing SQL databases. On the other hand, OLE DB has an improved architecture that provides a significant advantage over ODBC because providersno longer have to implement a SQL relational engine to expose data. An integral part of OLE DB is an OLE DB provider that enables OLE DB consumers to talk to ODBC drivers.
With ODBC, services such as cursoring and query processing need to be implemented by each ODBC driver writer. This represents overhead and possible inconsistency for both for the ODBC driver author and their end users. With OLE DB, reusable service components handle the processing chores for a variety of data providers.
OLE DB simplifies the process of writing data providers, which means they should be developed faster and be of a higher quality. It also reduces the number of components installed on data consumer machines.
Use the following tips to guide your choice of which technology to use:
If you are accessing standard relational databases from a non-OLE environment, ODBC is the best choice.
If you want to expose a data interface to nontabular data or use data from a source that does not support SQL, OLE DB is the best choice.
If you are programming in a COM environment, OLE DB is the best choice.
If you want to build interoperable database components, OLE DB is the only choice.
Technical differences between ODBC and OLE DB are summarized in the following table.
ODBC OLE DB
Data access API Database component APIs
C-level API COM API
SQL-based tabular data All tabular and multidimensional data
SQL-based standard COM-based standard
Native providers provide all features Component architecture allows reusable components to provide common features
Special Features and Benefits of OLE DB
As application developers move to solutions designed as reusable components, OLE DB enables business-centered components to behave and communicate like mini-databases, both as data consumers of other data sources and as providers. This capability is the basis for new, simpler ways to build applications based on components.
Access to all your corporate data regardless of storage format or location
This capability extends across corporate data as well as Internet data, and across all types of data providers beyond SQL databases.
Simplified programming model for corporate developers
When a developer uses a tool or language that supports OLE DB, different data sources can behave as a single, homogeneous source. From ADO, developers can create business applications that link many data sources.
Interoperable data-centered components
Business components can excrete data change events, consume OLE DB data, and provide OLE DB data. In this way, business components can perform very complex processing and synchronize with other components while exposing simple, table-like interfaces.
Components that act as virtual tables for quicker application development
Most graphical development tools automate loading OLE DB result sets from queries directly into user-interface controls. This technique is called data binding. Without OLE DB, more programming is required to access the result set and load the user-interface controls. Additionally, OLE DB supports events, or callback interfaces, which allow these controls to be more responsive and efficient.
Integration with the Microsoft suite of application development products and technologies
OLE DB is a useful technology in its own right, but it becomes even more compelling as the broad suite of Microsoft enterprise tools and technologies integrate and extend one another's capabilities.
Full integration with ODBC
OLE DB data consumer tools and languages have full access to all ODBC drivers and ODBC-based data.
ADO vs. DAO or RDO
ADO is now the standard data access language for Microsoft tools. The current versions of Internet Information Server, Internet Explorer, Visual Basic, Visual InterDev? Visual C++, and Microsoft Visual J++? have all been written to use ADO as their primary data access language.
Among the many benefits of ADO is a common language for accessing data. Whatever tool you are using, you can use the same code to query and manipulate data. This allows for much greater and easier code reuse across applications than was possible in the past.
Therefore, if you are designing an application now, you should use ADO, unless there are features you need that are not available in ADO but are available in one of the alternative technologies. Be sure to look at the features that are available through the ADO Extensions for Data Definition Language and Security (ADOX) library and the Jet and Replication Objects (JRO) library for features that were previously available only through DAO.
If you are using DAO or RDO, you should still think about how to move over to ADO when it supersedes these. That way, when the time comes, you will have an easier job migrating to ADO.
Following are scenarios in which you might still want to use DAO:
You have an existing application that uses DAO with Microsoft Jet, and you want to convert the application to use ODBC data to achieve better performance.
You need to create specific user and group PIDs when managing security access in a Microsoft Jet database.
You need security control over Microsoft Access objects stored in a Microsoft Jet database.
You need to lock a table exclusively in a Microsoft Jet database.
You need to retrieve implicit permissions on objects, in addition to explicit permissions.
You need to identify indexes that result from the creation of a foreign key in a relationship.
Following are scenarios in which you might still want to use RDO:
You are developing in Visual Basic 5.0, and you want to take advantage of binding controls with RDO.
ADO, DAO, RDO Feature Comparison
To help you decide which technology to use and also to determine if ADO meets your needs today, the following table presents a list of major features found in ADO, DAO, and RDO. ("X" indicates that the feature is present.)
Feature ADO 2.6 DAO 3.6 RDO 2.0
Asynchronous connect X ?X
Queries run asynchronously X ?X
Batch updates and error handling X X X
Disconnected recordsets X ?X
Events X ?X
Integration with data binding in Visual Basic 6.0 X ??br>Integration with Visual Basic/Visual C++ Transact-SQL Debugger ??X
Data shaping X ??br>Persistent recordsets (as binary or XML) X ??br>Distributed transactions X ?X
Thread-safe X X X
Free-threaded X ??br>In/out/return value parameters X X X
Independently created objects X X1 X
Queries as methods X ?X
Multiple recordsets returned X X X
Efficient Microsoft Jet database access X2 X ?br>
1 DDL objects
2 Using the OLE DB Provider for Microsoft Jet
|
|
|
|
|
|
|
|
| Re: oracle vb connectivity problem [message #104422 is a reply to message #104394] |
Tue, 12 October 2004 00:19 |
Vikas Kale
Messages: 8
Registered: March 2002
|
Junior Member |
|
|
|
The connectivity is easily possible through ODBC. Create your own DATA SOURCE NAME (DSN) and use it in your VB programs. If your ODBC DRIVER is not supporting then you can download it from the WWW.ORACLE.COM site for which you will have to register yourself into it. If still you have problems the plz reinstall both VB and ORACLE.
|
|
|
|
] 
Blog
Search
Help
Members
Register
Login
Home
