Is it possible to bind a msflexgrid/mshflexgrid to a custom datasource in vb6?
Yes of course you can. This was one of the new features in VB6.
See Using the DataGrid Control with a Class Module which is for a DataGrid but the same thing works with the FlexGrids.
You can create data-aware Classes and UserControls, or you can create an OLEDB Simple provider.
Related
So basically i have created user-defined JDBC provider through wsadmin:
AdminTask.createJDBCProvider('[-scope Cluster=MyCluster -databaseType User-defined -providerType "User-defined JDBC Provider" -implementationType User-defined -name "MSSQL JDBC Provider" -description "Microsoft SQL Server JDBC Driver" -classpath [${SQL_PATH}/sql.jar ] -nativePath "" -implementationClassName com.microsoft.sqlserver.jdbc.SQLServerConnectionPoolDataSource ]')
After that i want to create datasource. So basically when i use UI to create datasource - it fills 3 pages with custom properties (J2EEResourcePropertySet) of that datasource (55 J2EEResourceProperties).
If i use wsadmin it does not fills those 3 pages for some reason only i see ~8 custom properties (J2EEResourceProperties).
If i look at log command assistance commands when creating trough UI and script - those are the same.
Can someone explain me what is wrong? I need to have 55 custom properties when running a script also. Thanks.
Here is my datasource script:
jdbcprovider = AdminConfig.getid('/JDBCProvider:MSSQL JDBC Provider/')
AdminTask.createDatasource(jdbcprovider, '[-name DataSource1 -jndiName DataSource1 -dataStoreHelperClassName com.ibm.websphere.rsadapter.MicrosoftSQLServerDataStoreHelper -containerManagedPersistence true -componentManagedAuthenticationAlias SAmgr/DataSource1 ]')
Adding images to understand:
55 custom properties appeared:
Creating datasource trough UI Custom Properties:
8 custom properties appeared:
Creating datasource trough wsadmin script custom properties
EDIT: When you create a DataSource using a JDBC provider created using one of the pre-defined types, like MS SQL Server JDBC Driver, WAS uses the contents of a template to populate (among other things) the properties of the datasource. There is a template for both the 8 WebSphere properties (like webSphereDefaultQueryTimeout), and the other vendor-specific properties (like applicationName for MSSQL Server). The 8 WebSphere specific properties are common to all datasources and are maintained by WAS and are not properties of the JDBC driver. The properties in the vendor-specific template are a subset of all the vendor properties based on our assessment of whether it is “safe” to set/unset the property in a managed (JEE app server) environment.
Whether you create the datasource from the admin console or wsadmin, when the JDBC provider is based on one of the predefined vendors, the property set is the same since it’s coming from standard templates. The behavior difference you're seeing is because you’re creating a user-defined JDBC provider and not using one of the predefined ones. Typically, user-defined JDBC providers are only needed when the JDBC driver you want to use is not one of the pre-defined ones. When you create a datasource from a user-defined JDBC provider using the admin console, behind the scenes it is calling a method to introspect the driver and discover any public javabeans that the JDBC driver exposes as properties. The admin console then adds these properties to the datasource in addition to the 8 WebSphere properties from the template discussed above. The admin console performs the introspection because there is no template available for the vendor properties. However, when you create a datasource from a user-defined JDBC provider using wsadmin, it doesn’t perform that introspection, thus the only properties you see on the datasource will be the 8 WebSphere properties from the template discussed above. There are instances where the console executes some steps programmatically vs. via scripting and differences in behavior like this can arise. So, that's the answer to "why the difference”. After investigation, there no option to have the wsadmin command introspect the driver adding the additional properties.
I see two ways you can address the issue and get the properties added.
If the set of driver properties you need is part of those included in the standard template for that driver, change from creating a user-defined JDBC provider to using one created with that driver vendor. Using wsadmin, you’ll get all the same properties you would get if you created it from the admin console. If some, but not all of the property(s) you need are in the template, you can add those properties via scripting using the AdminConfig.create(…) method as you suggested. After your config is saved, all objects created via scripting will be available to see in the admin console, including the custom properties.
I have a Kendo grid and backend in ASP.WebApi
In Kendo Mvc there is the class DataSourceRequest and with the extension ToDataSourceResult you can filter your datasources with the parameters from the grid in the view.
Now i'm creating an application with HTML5 and Angular. For this solution i don't find a dll provided by Telerik.
Is there a way to easy take in the grid parameters (paging, sorting, filtering) and apply them to my IQueryable datasource?
There are two ways to do that:
Use the Kendo.DynamicLinq open source library
Use UI for ASP.NET MVC. There is a help article that shows how to do that from JavaScript.
I need to create some functionality that will be used by nearly all my controllers.
So I need to create a custom class. Now do I do this as a Core class? Or as a library? How do these differ?
I use the core class override technique when there's some behavior of one of the core classes that I want to change project wide. A great example of this is using Jamie Rumbelow's model class in /core/MY_Model.
For functionality that will be USED in each controller, I build a library to perform those functions and autoload it, then call the functions from that library as needed.
You want a library is you are developing a class. For simple functions, create a helper. If you are developing functionality that interacts with your database, create a model.
Add your custom helpers and libraries in you application folder.
I will start to code a new Web application soon. The application will be built using ASP.Net MVC 3 and Entity Framework 4.1 (Database First approach). Instead of using the default EntityObject classes, I will create POCO classes using the ADO.NET POCO Entity Generator.
When I create POCOs using this tool, it automatically adds the Virtual keyword to all properties for change tracking and navigation properties for lazy loading.
I have however read and seen from demonstrations, that Julie Lerman (EF Guru!) seems to turn off lazy loading and also modifies her POCO template so that the Virtual keyword is removed from her POCO classes. Julie states the reason why she does this is because she is writing applications for WCF services and using the Virtual keyword with this causes a Serialization issue. She says, as an object is getting serialized, the serializer is touching the navigation properties which then triggers lazy loading, and before you know it you are pulling the whole database across the wire.
I think Julie was perhaps exagarating when she said this could pull the whole database across the wire, however, even so, this thought scares me!
My question is (finally), should I also remove the Virtual keyword from my POCO classes for my MVC application and use DectectChanges for my change tracking and Eager Loading to request navigation properties.
Your help with this would be greatly appreciated.
Thanks as ever.
Serialization can indeed trigger lazy loading because the getter of the navigation property doesn't have a way to detect if the caller is the serializer or user code.
This is not the only issue: whether you have virtual navigation properties or all properties as virtual EF will create a proxy type at runtime for your entities, therefore entity instances the serializer will have to deal with at runtime will typically be of a type different from the one you defined.
Julie's recommendations are the simplest and most reasonable way to deal with the issues, but if you still want to work with the capabilities of proxies most of the time and only sometimes serialize them with WCF, there are other workarounds available:
You can use a DataContractResolver to map the proxy types to be serialized as the original types
You can also turn off lazy loading only when you are about to serialize a graph
More details are contained in this blog post: http://blogs.msdn.com/b/adonet/archive/2010/01/05/poco-proxies-part-2-serializing-poco-proxies.aspx
Besides this, my recommendation would be that you use the DbContext template and not the POCO template. DbContext is the new API we released as part of EF 4.1 with the goal of providing greater productivity. It has several advantages like the fact that it will automatically perform DetectChanges so that you won't need in general to care about calling the method yourself. Also the POCO entities we generate for DbContext are simpler than the ones that we generate with the POCO templates. You should be able to find lots of MVC exampels using DbContext.
Well it depends on your need, if you are going to serialize your POCO classes than yes you should remove them (For example: when using WCF services or basically anything that will serialize your entire object). But if you are just building a web app that needs to access your classes than I would leave them in your classes as you control the objects that you will access in your classes through your code.
I have an MVC3 project with a requirement to use LDAP to fill in several personnel properties on one of my Model classes. I have done this before in .Net 3.5 but wasn't sure how to approach it in MVC3. Would I take the same approach or is there an HTML helper or some other mechanism in MVC3 that I could/should use?
Keep doing what you have been doing. When building your ViewModel (preferably in a repository layer), you can use LDAP as your data source for the necessary properties.
You do not want to do this in a view, as the view should not have any logic other than presentation logic.