Are there any restrictions on the names of tables, or issues with certain names when working with SubSonic?
I have table called 'Activity' and SubSonic doesn't seem to recognise it. When it was called 'Activities' it worked fine.
Basically I am wanting to go with singular table names as a convention (and the other conventions as detailed in the SubSonic Conventions blog post) and added fixPluralClassNames="false" to the web.config (because I have a table called 'Focus', which SubSonic kept naming 'Focu')
Generally, reserved words in C# are not allowed as table names. I'm not sure why Activity would be a problem though. The first thing to check when a table is not generated is that the table has a primary key.
One common problem that I ran into was it would not work if my tables begin with special characters or numbers. Changing that fixed it on my end. Apart from that I did not run into any other issues.
Clearing files in the Temporary ASP.NET Files folder (After closing Visual Studio), or changing the .abp file seems to be a valid fix to this.
Related
I have a couple of custom tables I created and a few screens, imports, etc. based on them. Then realized I didn't prefix with our own 2 character tenant. Seemed like a simple refactor but If I rename SQL tables and the DAC classes (I'm using extension library) then my ASPX/Screen editor is broken (did not rename Graphs or Graph views) Tried to modify ASPX markup and reload changed files but then I wound up with an empty screen in screen editor. I'm putting everything back and restoring from previous day package export for now. Any tips/tricks for renaming SQL/DAC classes. I looked at PXTableName attribute (to try to keep code the same and only change SQL tables) but could not understand why that requires another virtual/abstract class.
Update: Tried again and this time no problems just renaming DAC and SQL table. Not sure what mistake I made the first time.
I'm trying to wrap my head around it. I've checked other questions and nothing seems to be too similar.
The Office 2013 development centre contains extensive DAO examples and states it is one of the easiest ways to work with an Access file (does not require an Access window) but DAO is a deprecated technology. (https://msdn.microsoft.com/en-us/library/office/ff834801.aspx)
I'm trying to write an Excel Add-in (eventual end point) that will grade Access assignments in .accdb format.
I'm can't just use ADODB to perform SQL queries to extract data, unless SQL can also do the following:
check a specified report has a specified title
check that specified tables, queries, forms, and reports exist
check specific fields in a table exist
check that specific fields have been set as the Primary Key
I also need to check that certain values exist in a table, but those I can solve with SQL.
So should I be using DAO or stick with ADODB? Remember, I'm using Excel, not programming in Access VBA.
The simplest way to work with excel tables is to link them in Access either manually or via the TransferSpreadsheet function in VBA. If you use a generic naming standard for the file names and tab names in Excel, you will not have to relink, rather you can replace the Excel file and the Access link will read the new file unless the layout has changed.
Once linked you can use the query-by-example tool to write your queries which also can be written into code (i.e. either embedded in the VBA [old school and not a best practice] or saved in an Access table then looked up and assigned to a variable for use with the CurrentDb.Execute strSQL, dbFailOnError command.
I suggest manually linking the first go round so you can manually define the individual column types vs. letting Access mess it up.
If you cannot use generic names and have to pick the file via a browse dialog, you can get a file browse function via Google to allow you to programatically link the file. (or you can rename it to a generic name which works even better)
So DAO vs. ADODB is moot from an Access perspective. I supported 50 databases with 70,000+ lines of code and dozens of Excel source files the past 4 years and never had to ponder the question.
Microsoft originally deprecated DAO in favor of ADO, but recently renamed DAO to Microsoft Access Engine (ACE) and is now pushing it as the preferred data access technology for Automation-supported environments (VBA, WSH etc.)
In general, in your scenario I don't think it makes much of a difference which one you use. I suggest you read through this.
I don't think it's possible to read table/query/field information via SQL. However, this can be done either with the DAO.TableDefs and DAO.QueryDefs collection, or the ADO.OpenSchema method.
RE: forms/reports - I don't know if it's possible to read form/report information via DAO or ADO even without SQL, as it is actually part of the UI objects, and not the data; unless we're talking about reading/parsing the system tables. You may have to open the database in a hidden Access instance and read the forms/reports that way.
I ran into my first Core Data versioning problem - learn something every day!
Following instructions found here, I made a new version of the model, added the code for lightweight migration, and then went to set the active version…
Uhhh, where do you do that? The docs don't actually say, and other threads here talk about "click on the main file". WHAT "main file"?
The original xcdatamodel has no version number in it. Is that a problem? Is the Migration Manager still going to be able to figure this out?
All I did was add a field, this seems like a lot of work…
Core Data model files don't use version numbers. The files might include a number in their name, but that's for people to see, Core Data doesn't care about it. It uses entity hashes to compare models.
The "main file" is the .xcdatamodeld that contains all the versions (which have names ending in .xcdatamodel).
Select that then look in the file inspector pane on the right. It has a pop-up menu that you use to select the current version.
I have been using SubSonic 2 on several projects before but with the new SubSonic 3 I have implemented in 2 projects. However, my question has always been is if I can change the the output T4 template to generate a class file for each table instead of single ActiveRecord.cs file. I want to use it in a very large project and I can see where is not practical to have 80+ tables in a single file. I prefer to have separate class files.
Would I need to change SubSonic.Core?
If its not possible, please let me know.
Thanks
Why does it matter how many files there are if the code is entirely generated? What practical difference is there?
You can change the templates to output multiple files. No changes would be required to the SubSonic dll, just the T4 Templates.
However, I fail to see how it is worth even just the time to post the question here, much less the time required to actually make those changes.
There is a way to do this, if you rewrite the T4s to follow this example. However, I think there is an issue that may arise when you drop a table, the previously created .cs file for that table will not be removed. I think you would have to further edit the T4 to start by deleting all its previously generated files.
When generating my DAL files with SubSonic, I'd like the names of the files to be .gen.cs. The main reason for this is that the files are partial classes, and I would like to add some additional implementation details into another source file for the table called .cs. This is somewhat the standard pattern for generated source files , and I'm wondering if its possible with SubSonic? I'm using SubSonic 2.2.
I thought you might be able to do this by using a set of custom templates, but the CS_ClassTemplate.aspx (or VB_ClassTemplate.aspx) doesn't control the file name of the class.
I don't think this is possible.
As an alternative, you can do what I do. I have a "generated" directory, such as \database\generated and then I put my partial classes at \database\custom. As long as the namespaces of the files in the two different directories match (like .database or whatever), then it works fine. By using two different directories, it's easier to find your custom files without looking at the generated ones.