For development within our Oracle 11g database we use Toad for Oracle and Git (in TeamCoding).
One of our development rules is to use the Toad Autoformatter to have a persistent "code appearance". Since we want to change this rule set (towards less line usage), every file would be entirely in the changelog when switching from old to new formatting, making it impossible to see the actual change diff.
Also db objects would only switch to new formatting when being changed.
Is there a way to apply the Toad Formatting rules to all objects (in the database via Toad or maybe in the Git directory)? Then we could make a minor Version which only switches all objects from old to new formatting. :)
Thanks in advance!
ps: manually doing this would be possible ofc, but could take some time since we have a lot of objects in the database :D
Facing the same problem, I could not find a complete massive way; the best thing I can do is:
go to Schema Browser
select all the objects
do "Create script"; in "Script options" panel you'll find the format option, so you can download formatted code.
compile all the objects to save formatted code on DB
In this way you neeed to navigate a bit through the browser, but I hope this can help anyway.
(tested on Toad 12.1.0.22)
Related
We are looking to introduce odac into our application but I am running into a number of issues and I can't seem to find any solutions that fix our issues.
We are using an oracle database and trying to use ODAC 12c Release 1 (12.1.0.1.0) with Oracle Developer Tools for Visual Studio.
In our model we would like to have multiple schemas so we can perform cross schema queries. The schemas which we select in the filter for the database connection appear when we are creating the model. However when we try to update our model from the database only the default schema is visible. Sometimes this can be fixed by opening the relevant part of the database in Server Explorer in Visual Studio but this doesn't always work. This fix never works after we add multiple connection strings for the same model (depending on the location of the user will depend on which database the user gets directed to).
The next issue we are having is that we can't the return types of stored procedures to be auto-generate. I have tried to retrieve the column information but it is never able to retrieve the metadata. I have seen a few suggestions of modifying the stored procedures then getting the column information and reverting the stored procedures but this is something we would like to avoid. Also the suggestions don't seem to work on oracle databases (but that could be me, I don't have much experience with databases).
The final issue (this is a minor issue) is that I cannot figure out how to get the generate code to omit underscores from the classes/methods generated. This isn't a huge issue it is purely to make it easier migrating the code we have.
I have a schema in an Oracle 11g R2 database that I'm trying to connect Crystal Reports.
I have two users; an admin user (where I create the views, etc.) and a reporting user that has the ability to query certain tables/views.
In any other database tool (SQL Developer, TOAD, DB Visualizer), I can see the schema along its tables and views, and can query against them and create new views, etc. as I should be able to.
However, in Crystal Reports 2008, when attempting to access the data, the proper schemas/views aren't displayed. Examples:
Creating an ODBC datasource in Crystal (which I believe connects to one I've pre-created in windows that works just fine), only a small subset of schemas are shown in Crystal (but not the one I should be able to see).
Creating an Oracle datasource in Crystal shows me the schema, and all of the tables I believe, but only one of the views (not the one I need).
NOTE: Normally I would think that it's a permissions issue on the database, except that I can access these schemas/tables/views properly from every other client I've tried.
Any ideas? Is it the drivers that Crystal 2008 uses? Is it still somehow possibly a permissions issue? I'd appreciate any insight you fine folks have.
Looks like this was indeed an error on our DBA's part. A certain level of "select" permissions in their permission model was preventing access. It appears to have been resolved.
But if anyone would like to help me gather all copies of Crystal 2008 in a warehouse and light them on fire, be my guest. :)
I've got a better one...
I was working with this for a long time today, trying to help one of our new developers. He had developed a report from a different workstation against a different data source, and we needed to swap the data source when we transferred it to the new network. Fired up CR, Showed him how to "Set Datasource Location", we get the account information, check the connection string, etc. Get ready to show him how to replace one db w/ another... find the connection, open the server, pop out the databases, open the database to show the tables and... Nothing. Hm...
Try a different account that I know works. Strange, THAT one doesn't see any tables either. Try a different database. OK, now I'm a little off-balance... Remote into the web server to see if I can run one from there. Fire up CR, Open an existing report, hit refresh, put the PW in, and voila! Data. Lots. Copy his report up, remote in, open it, get ready to Set Datasource Location, and ... nothing.
Spoke w/ the DBA, watched/walked him through the check, still nothing.
Funny thing was, if I had a report that had connected before, it would run. Wonderful! Check the available tables... nothing. Quick jump to look at the db... I can see the privileges, I can see everything set fine. Cool. Tried again, nothing.
OK, spoke to another DBA. I walk him through CR to show him the issue, he and I are going to explicitly set permissions. I open the data source in CR, right click to look at Properties, and... noticed that I hadn't check Options. Sinking feeling in the pit of my stomach. Open Options, and notice in the Data Explorer section, TABLES is not checked.
I remember WHY I set it... a long time ago. The DB has thousands of tables, and I knew which ones I needed. I paste a command and go, I never CHOOSE tables.
So... Check TABLES, and thousands of tables show up again. Sigh.
OPEN CRYSTAL REPORT THEN CLICK FILE -> OPTIONS -> SELECT TAB DATABASE -> IN THE EXPLORER OPTIONS PUT TICK MARK ON TABLES AND Onwer Like < add schema name> click ok
this will list only that schema. Crystal Report has some limit is loading all table names so select the scheme so that it will load only that schema.
thanks,
praveen.
I usually create a solution folder in Visual Studio and put my DB scripts in them. I always use at least this set of scripts:
Drop model
Create model script
User functions
Stored procedures
Static data (lookup tables)
Test data (not deployed)
Then I simply combine them and run against an SQL Server so I'm able to recreate the whole DB in a single step (by combining these scripts into a single one and executing it).
Anyway. I've never used projects in either:
Visual Studio or
SQL Management Studio
I've tried creating SQL Server 2008 Database Project in Visual Studio 2010, but I'm somehow overwhelmed by all the possible server settings (which I prefer to stay default as set on the server anyway). So I'm a bit confused: Should I use this project template or should I just do the same thing I always did?
What do you use and why? What are advantages I may benefit from by using either?
If I were you I would continue to do it the way you are doing it. In fact I do! The advantages of having the actual .sql files right there in a folder for you to use/edit/look at in my opinion are far better than the advantages you get by using a DB project. DB Project would be used if you were doing something like Storage Reports, were you have to communicate with like 8 databases and compare then to 8 different databases and save result sets etc... Now don't get my wrong there are advantages of Database Projects, I just don't think they are actually doing much help when you have such a simple setup that works already.
Advantages of the SQL Server 2008 Database Project in VS10:
Not having to switch back and forth
from your current client you use to
communicate with your SQL server.
Decent Data and Schema compare tools.
Gives you a one-click way to reverse
engineer a database into source
control, and keep it up to date.
You can compare projects to physical
databases and vice-versa. (This makes it pretty easy to keep your database up to date, no matter where you make change it: file system database project, or in the physical database itself)
If the current tool your using is not specifically tailored to SQL Server, this one is.
Extremely helpful if you need to do
unit tests directly on the database
without using abstractions.
If you're looking for something a little less complicated, you might want to try SQL Source Control. This won't even require you to maintain scripts, as it doesn't this for you behind the scenes. It will, however, only work as a solution for you if you use either TFS or SVN. And it costs $295...
It has a 28-day trial period, so if you're happy to try it out, I'd be interested in your feedback.
I'm generating domain model using LINQ to SQL via the VS2008 built-in editor. That works really well, too; when I adjust my database schema I simply delete everything from the editor and then pull it back in from the server explorer by selecting all tables and dragging them into the designer surface. That works great too.
Now the problem: I have properties that I manually set to autogenerated, readonly etc. using the property inspector on the right. Everything I re-create the entire schema I have to do this manually all over again.
Is there a way to persist these settings externally and/or automate them to bring it back to the state from before?
You can use something like the Huagati DBML Tools. This will allow you to update the DBML file from the VS designer.
I've also used the following process before:
Create my schema in SSMS
Create a script that uses the SQL Metal command line tool to generate the DBML file
As the DBML file is XML, you can run transformations on the file. I used this to simply change a few things like setting certain fields to be auto-generated (DateCreated, etc).
Then, either use SQL Metal or T4 to create the model files from the altered DBML file.
This process worked great - however I had complete control over the database schema. This process also allowed me to use L2S with SQL Server Compact Edition.
Hope this helps!
T4 Toolbox has a Linq to Sql Schema generator which allows you to develop your Linq to Sql applications in a model first approach. I have used it a little and it works really well, here is a blog post with details and usage info.
Your solution may appear to work when you have very few database entities / tables, but it does not scale and as you've found, syncing is less than ideal.
Do not use the Visual Studio 2008 LinqToSql O/R Designer
After looking at many alternatives to the problems you are describing with LinqToSql, I decided to abandon LinqToSql altogether as I didn't find any of the workarounds very good. Competing ORMs don't have the silly problems that LinqToSql has and they are much more mature and feature rich.
I could/should probably list some of the alternatives I ran across, but I don't want to spend the time and give you false hope, sorry.
I'm fairly new to LINQ to SQL, so I could be missing something basic here.
I created a LINQ to SQL layer, generated all the dbml files etc., and created a LINQ query which worked fine. I then made a change to the database, and wanted to get that change reflected in the ORM layer. To do this, I deleted my ORM layer and created a new one (may not be the best way?).
Now my code is not able to see the datacontext object in intellisense and won't compile. I imagine this may be something simple, but I'd also like to understand the bigger picture of how to update the LINQ to SQL ORM layer when the database changes.
Yeah, you don't want to delete your whole DBML file. Open it in the designer, and delete the table that changed. Then drag'n'drop it again from the "Server Explorer" (in the view menu). This will load an updated copy of teh database...
Note that if server explorer is already open while you make the change to the SQL schema, you'll need to refresh server explorer so it has the latest versions.
The drawback to this approach is that if you do customizations to the table in the DBML, those need to be redone. This is an infrequent case for me.
I remember having this issue a bunch. The fix is simple, really. Rebuild your solution! The DataContext and other such classes are generated during a build.
Quite a headache - I wish the DBML tool did this for you when you closed it.
You can also use SQLMetal to update your DBML classes. Some people even write a script or batch file to automate the process.