Linq to SQL: How do I stop the auto generated object name from being renamed? - sql

In visual studio 2008, when I drag a database table into my dbml screen, any tables that end with the letter s automatcially get the s removed from the dbml object. Is there any way to disable this?
Also, the collection of rows also gets an s appended to the collection property name. Is there a way to change that as well?
Thanks

You need to disable the Pluralize Table Names for the LINQ to SQL designer.
To do this navigate to Tools -> Options -> Database Tools -> O/R Designer and change the Pluralization of names to false.
Then you will need to recompile your project and it should address the naming

In a code first scenario, you can handle some problems that pop up like this on a more granular level by simply specifying the name of the table on the entity with the Table attribute:
[Table("QTPhotos")]
public class QTPhoto
What I found was, originally, we had a simple entity name "Photo," but this was conflicting with some things (with a number of our entity names), so we started qualifying them ("QT" as a sample prepend), and suddenly this problem popped up. So I bet this is because "Photo" is a recognized word ending in 'o' that does not pluralize to "..oes" (as in Potatoes), but "QTPhoto" was not, meaning it was trying to find a table named "QTPhotoes".
Simply setting the table name fixes this.

Related

Fields on form, selected from data source are not available when using Me

I have two fields on a form. Field 1 is auto number field named 5sID. Field 2 is a lookup field named 5sType.
When I open the VBA code for both the oncurrent and on open, I try to reference either field with a "Me.5sID" or "Me.5sType". In either case when I type in the "Me." the auto list shows the other eight fields in the table, but not these two.
I have used this for years on both datasheets or continuous forms. There are only the two fields on the form and they were selected from the table field list in the design view.
If I change the name on the Other tab of the property options, the fields then appear.
I have now rebuilt the table and the form, I have created a database and linked to the same table and still get the same results.
If I add another short text field it shows up when I type "Me." in VBA, but any other type of field does not show up.
Naming an identifier with a number as first character is a bad idea! Always start with a letter!
On Access 2013 that creates a compile error as the compiler expects a=as he interprets.5as a decimal-number.
That worked for you on older versions? Hard to believe!
As workaround use square-brackets like on identifiers containing spaces or other crap.
Me.[5sID]
or turn onShow hidden Elementsin Object-Browser , what fixes Inteli-Sense and creates automatic brackets. Seems like this is a way to create hidden members ;)

Change the source of a dimension in one go?

This is one of those "where the **** did Visual Studio put the button to do that? You must be able to..." questions.
A dimension in an SSAS project runs off a table in the DSV. Now I've created a named query (which just excludes certain unwanted rows from the table). How do I switch the dimension over to point to this named query? Nothing's changed in the set of columns.
What I did was to go to every attribute, and change the Source of its KeyColumn (and NameColumn, where appropriate) to the named query - which involved reselecting the same column name.
There just has to be a better way to do this...
I found it in the end.
You don't do this in the dimension itself, which takes the "friendly name" of the object overlaid on the real datasource in the DSV as its source.
Instead, you "point" that friendly name to a different database object (table, view) in the DSV itself: right-click the object and select "Replace Table".
Note that the "friendly name" won't change, so that it will look as if nothing has happened, until you see that the Name property has changed to point to the object you just chose. (I usually change the friendly name to give at least some information about the underlying database object).

Get column name & table name from value

Actually I have a new client & their Database has no standard naming conventions & the application is in classic asp.I have a form in which a form there are many values in the different textboxes, it it very difficult to trace the value come from which table.& also there is no erd.
I need a query from which I can get the table name with column name by giving Value.
Let's suppose I have a value having label name abc#= '6599912268'
& the new project has no ERD no standard of naming conventions... I need a fast way to know the abc# ='6599912268' is taking from which table & which column name.... like this the UI has many values which is time taken to trace manually
Is there any way to trace it?
The simple answer is no. There is no way to trace table/column it comes from by mere inspection of the value.
I suggest the following.
Find out what type of db your product is using. Where it is situatede, do you have access to it.
If you have access to the database, get to know the db structure. What each table is meant to store, the relationships etc. Speak to the db administrator or the business analayst to increase your knowledge on the product domain.
Once you have the db structure, try and compare the table to the page. Eg. The user details will most like be stored in a db table named 'Users' or 'Membership' Catch my drift?
Then have a look at the web sites source code. Look at the specific page you are at. Is the sql code embedded in the source code (asp page) or does it call a COM server or something similar? If you are "lucky" (and I say lucky for on the purpose of your problem that you are having) you fill find the sql code in the asp page.
If it calls a COM object or something similar, then you will have to dig up the source code for that, and that is most likely where you sql will reside.
There is no easy way to do this, you have to use a stored procedure to loop over all the tables in the database and search for the value, and it will probably take a while.
There's a stored procedure and examples here: Search all columns in all the tables in a database for a specific value. You'll see there are stored procedures for finding dates, strings, numbers.
Not possible, and If you search the column with the value, there is a possible chance that you get multiple columns with the same value, so how would you differentiate them and the same case is for the table.

Error 3031 mapping fragments starting at line 439:Non-nullable column

Error 3031: Problem in mapping fragments starting at line 439:Non-nullable column D_LINK.CARTON_QTY in table D_LINK is mapped to a nullable entity property.
I have a view D_LINK with a column
CARTON_QTY(int, not null)
I dont understand where is my problem
do i have to make it null \ how?
refresh the table in your edmx from your database (In model browser, right-click-->Update Model From database --> update tab --> select your table -->click update)
The error says that your column in the table / view is not nullable but the property of the class in entity model is nullable. They must both be either nullable or not nullable.
Just delete that particular table from the model and add it again. That will solve your problem.
I got this issue after changing a none-nullable column to a nullable one.
What solved it for me was the following:
Manually edit the column and the link the column had to another table to (0...1) in the .edbx file.
After the manual edit do a update table like DRM described.
One of the actions alone did not solve my problem(feels like a glitch). Hope this can help someone.
This is on EF 4.5 that I am finding this, previous versions may not have this exact problem.
DRM mentions the way to update it, but I have found that sometimes even when you update it some of the minor changes like switching required fields or changing the field names it doesn't change them in the edmx even though you update it. Therefore your data models don't match the database exactly.
I have found the best way to ensure your edmx entity models are correct is to delete the edmx and re-add it. After doing the database first approach on EF 4.5 I think that Entity seems to play more nicely with the code first approach instead of database first.
If you want to keep the record. Only undo removes the error otherwise rebuilt table
I got it solved by
1. Delete the particular tables from the model
2. Right click on the model, select Update model from the database, select the deleted tables and click finish.

#DBColumn in Lotus Notes

I've been tasked with learning Lotus Domino Designer - not sure what I did in a previous life, but it must have been pretty bad... - and was wondering how to do a lookup on a database to get some values for selections. As this information could potentially be used in a lot of the applications, I'd prefer it only to be in the one place.
I gather I can use #DBColumn, but what happens if an entry in that lookup changes? If the unique value of the lookup is the text, then the relationship would be broken, wouldn't it? Is there any way of mimicing the idea of relational lookups?
I'm assuming I'm looking at Lotus development from the wrong angle, as this seems to be a real limitation of look ups.
I haven't found any decent learning material on the interwebs, so would appreciate any help.
Ta
You would want to store a unique ID along with the textual value in the source database (not unlike what you would do in an RDBMS). Then, only store that ID in any referencing documents, and use a computed-for-display field to lookup the display value. (There is a performance consideration here - and you could "de-normalize" the data and store the ID and text value in the referencing documents, and do some asynchronous work to keep the values in sync - eg: using a scheduled agent that runs every night or every week).
If DB1 has the key values and DB2 has the documents which will reference these values, then in the form in DB2, you would still do a #DbColumn to lookup your value list. In the lookup view in DB1, concat the text value and ID with a pipe separator (textField + "|" + ID) in the first column. That will tell Notes to store only the ID value (what follows the pipe is the "alias" and is what will be stored).
Note: I would avoid using #DocumentUniqueID as the unique ID for these values, as the Document Unique ID will change if the documents are copied and pasted, or the entire database is copied, etc. You can use the #unique formula function in a computed-when-composed field to generate something close to a unique ID (almost like an identity column in sql).
If you need relational properties, look for non-Notes solutions. It is possible to get some relational behavior using document UNIDs and update agents, but it will be harder than with a proper relational backend.
Your specific problem with referencing to a piece of text that might change can to some extent be resolved by using aliases in the choice fields. If a dialog list contains values on the form...
Foo|id1
Bar|id2
...the form will display Foo but the back-end document will store the value id1 - (and this is what you will be able to show in standard views - although xpages could solve that). Using the #DocumentUniqueID for alias can be a good idea under some circumstances.
It depends on where your using the data. The #DBLookup or #DBColumn will work in Lotus Notes fields if the fields are set to be computed for display. That way they always get the most up to date information when you open the form etc.
If you make it so the data is saved on to the document then you will have to write some update code when you need to refresh the values.
The Lotus Notes help files for designer are pretty good, have a look at that.
SM
You could use a key or alias to store the relationship to your lookup value so if the value itself changes, the connection remains because the alias is intact. For example, if your lookup values were being stored as a collection of documents, I'd have the #DBColumn retrieve Document UNID|lookup value pairs. When in display mode, you could then retrive the value using #GetDocField. If the lookup values are in a different database, then you'd have to retrieve them for display using #DBLookup and construct a view that is keyed off of the UNID or whatever key you decide to use.The only drawback to this technique is that you wouldn't be able to display the field value in views as the actual value isn't stored in the document, just a reference to it. Using XPages, though, you COULD map the relationship into a dynamic datatable just like you would in a truly relational system.
It's tricky, but using LEI, you could also use Notes to front-end a relational backend system, also giving you the dynamic relationship you desire in your lookups.
Hope this helps!
The content of the lookup can change freely. A problem only arises (as it would on any other platform in the same circumstances) if the lookup key changes. You need to use a key that won't change. Human-readable text is an advantage, but if you want to be able to change your key description from, say, "Divisions" to "Business Units" and still have lookups work, you need to use an alias of some kind, which will presumably be mapped to your text description and only used internally. #Unique is pretty good for this, and gives a shortish key, if that is important to you. #DocumentUniqueID is most reliable, but as Ed pointed out, will change (must change - it's a new document) if you copy/paste or make a non-replica copy. This is easy to get around, though. Create a Computed-when-composed field (called, say, "LookupRef") on the form you are using for your reference document with the formula "#DocumentUniqueID". That will capture the ID at the time of creation, and it will not change on copy/paste etc. Use that as your key.