https://docs.oracle.com/database/121/RACAD/GUID-1A7346B1-AFE3-4B17-AD7E-E35FE628CDF9.htm#RACAD7136
Oracle ODP.Net provides way to capture FAN events when RAC goes up or down. Is there a way to capture this in C# code. I am not able to see any example of this.
Thanks
You can use the HA Events classes:
https://docs.oracle.com/en/database/oracle/oracle-data-access-components/19.3/odpnt/odp-dot-net-ha-event-classes.html
Related
I would like to create my own query language for a web api I wrote. But I have no idea where to start for it.
The language should be like SQL. For that I looked up the NHibernate code, cause I know, that they have the HQL (Hibernate Query Language) but it didn't help.
Are there any instructions or sth.? If this question is wrong here please move and/or tell me where I should ask else.
The first step is a lot of design work, starting be answering the following question:
Is this new Query Language going to be converted to SQL which will be
executed by a standard database engine, or are you going to write your
own database server as well?
If it's going to be converted to SQL (just like HQL) then map out the translations from your language to SQL on paper (and make sure you know the possible SQL constructs you may have to use). Once you've got that, you can start implementing it. Yes, this sounds like BDUF, but the language should be defined in one pass, I think, as it will be more consistent and easier to use if you do it that way. You can always implement it in a more Agile way once you've got that.
If you're going to write own database server, you're on your own....
I'm looking for som testing programs for a firebird db server, to stress-test and find bottlenecks.
Something like DB-Optimizer, only for firebird would be nice.
Can also be separate programs, one for stress-testing and one for profiling.
You may look :
sinatica monitor
IBSurgeon tools
IBExpert
and you can also just request monitoring tables (Firebird 2.1)
Just complementing Hugues answer:
Sinatica monitor uses monitoring tables from Firebird 2.1, so will not work very well on FB2.0 or below.
IBExpert have his own type of monitoring tables to help you in this task.
If you are using FB 2.5 you can look also Firebird Trace Manager.
To make some stress tests using your own application you can always look for AutoHotkey. Just be careful... Sometimes you can really mess things with it.
Jmeter may work rather well, as it's fairly easy to setup a basic DB request test, and can be incredibly flexible.
Overview
Manual
You may look at Firebird profiler to trace the queries
I need that Nhibernate only generate pure SQL, which I will send to my C functions.
Custom Driver
Build a driver that calls your C layer by implementing NHibernate.Driver.IDriver.
The SQLite driver is a good place to start as that is a C library. Your IDriver will be almost the same as SQLiteDriver. The NHibernate source code will be useful for this.
You will also need a IDbConnection wrapper for your C library. Of the SQLite wrappers, csharp-sqlite has the smallest source, it should be helpful.
Odbc
NHibenate already has a driver for ODBC connections, NHibernate.Driver.OdbcDriver.
There isn't a simple way to do this. In theory, NHibernate doesn't have to produce SQL at all; it's just that your dialect happens to (for example, it could just have some text files as the data store). The interface doesn't expose that the SQL because it breaks the abstraction barrier.
However, if you use the show_sql option, NHibernate will log the SQL, and you can use that. The only way I can think of is to set up a dummy database and run the NH queries against it. Build a custom log4net appender to capture the SQL and just store it in a variable. Now you can associate that with the query. So then you'd have something like
RunQueryAndCaptureSql(session.CreateQuery("from Stuff s where s.Thing = 'dude'"));
which blocks waiting for the appender to append the SQL and then returns that. Inelegant as hell and you'll have to make sure you deal with threading issues, but it should work.
Frankly, I'd probably just hack the NH source instead.
I am looking for information on the best practices or project layout for software that uses SQL embedded inside VB.NET or C#. The software will connect to a full SQL DB. The software was written in VB6 and ported to VB.NET, we want to update it to use .NET functionality but I am not sure where to start with my research. We are using Visual Studio 2005. All database manipulations are done from VB.
Update: To clarify. We are currently using SqlConnection, SqlDataAdapter, SqlDataReader to connect to the database. What I mean by embed is that the SQL stored procedures are scripted inside our VB code and then run on the db. All of our tables, stored procs, views, etc are all manipulated in the VB code. The layout of our code is quite messy. I am looking for a better architecture or pattern that we can use to organize our code.
Can you recommend any books, webpages, topics that I can google, etc to help me better understand the best way for us to do this.
I am looking for a better architecture or pattern that we can use to organize our code
...
topics that I can google
Take a look at DAL (Data Access Layer) for database transactions
Here is a link to a StackOverflow question posted by someone who is facing a similar situation
Creating a Class Library in VB.NET
When you google "How to create DAL", you will see list of how to create a DAL as well as what DAL is.
And here is a nice article that shows how DAL fits into an N-Tier achitecture
What is n-Tier Architecture?
Webopedia: N-Tier Application Architecture - Shows a nice graphical representation
It sounds like you're looking for a grand theoretical book that is written for one very specific case, i.e. what is the best practice for managing our current spaghetti SQL code framework, and I don't know that I've ever seen a book or document that describes that.
That being said, we converted several applications from VB6 to C# a few years back and were in the same place. Other than breaking apart certain modules so that their organization made more logical sense overall, our applications are essentially the same as they were, just rewritten in C#. I don't personally like the idea of separating SQL code from the function for which it was written (which is sort of what it sounds like you're trying to do); in general, if we have a function that needs to hit the database, we create a SqlCommand and, optionally, a SqlDataReader, set the CommandType to StoredProcedure and add the parameters, then perform the call and consume the result, doing with it whatever the function was programmed to do.
I don't know that that is the best way to do it, but it works for us.
Would it be possible to convert it to using LINQ? It's safer than converting it to using regular old embedded SQL statements.
In addition to what Sung Meister said, you should also consider moving the SQL from the VB.NET code into Stored Procedures, and then call the SPs from the VB.NET code (the Data Access Layer). It provides many advantages.
I'm looking for the single biggest reason you are glad that you've already made the jump from SQL2000 to SQL2005.
Recursion without creating temporary tables.
Native Exception support (Try/Catch instead of if #Error goto)
Because:
Microsoft would like to remind customers that support for SQL Server 2000 Service Pack 3a (SP3a) will end on July 10, 2007.
Native XML support is big for us here.
SSIS support. Blows DTS away and is quite handy. :)
SSRS - A really huge advantage for my organization is having the free reporting tools that come with SQL Server 2005. Reporting Services allows me to produce nice looking reports that have exactly the fields that our managers need in very little time. It has a built in tool so they can convert to excel, pdf, or several other formats. Lots of value here.
SSIS - Integration services in 2005 is very powerful for ETL (export, transform, load) functions. You can set up automated processes to run on a schedule.
SSAS - Analysis services looks promising. I have not made any data cubes yet because I want to organize an actual data warehouse. Once you have that, robust data mining algorithms are already built in.
Take a look at these three tools that are included with SQL Server 2005. If i had to pick one as the single biggest reason to move to 2005, it would be SSRS.
At this point, I would suggest looking at SQL Server 2008.
Pagination without (manually) creating temporary tables is a basic, but huge improvement.
However, if you are then going to drag & drop some GridViews in your ASP.NET app directly from the data table, you'd be paging in the app...
CLR integration
Row Versioning-Based Transaction Isolation
I think the single biggest reason is that SQL 2000 is not supported on Vista. I had to move to SQL 2005 because of that.
I don't know if it's just me, but Linq2SQL doesn't exactly work perfectly with SQL 2000. Ordinarily its supposed to automatically generate and populate child collections based on inferences from your schema's keys, foreign keys, RI, etc. Works fine in 2005 but i haven't had much luck in 2000.
Common Table Expressions have proven incredibly useful.
Exception handling... how did we ever manage on SQL 2000...?
PIVOT. That beautiful little statement has saved me more time then any other SQL Server 2005 enhancement.
YOU CAN'T EXPORT TABLES with a "right click" anymore. This is more of a problem than a good reason.
Dynamic Management Views
for Optimisation and to quickly find out the state of the server.