AWG Blogs

Tuesday, March 30, 2010

MIssing BIN DLLs from VS Website References

If you are ever in the predicament where after copying over a Visual Studio 2005 website to another machine and are not finished working out the dependencies, here's a tip: Make sure all the assemblies listed in the "add assembly" tags in the web.config can be found on the current machine first, or else none of the Bin folder DLLs will be added as references, no matter how hard you try.

I ran into this problem, and Visual Studio 2005 refused to add the Bin folder references, until those web.config assemblies had their match in the GAC. Go figure!

Tuesday, March 16, 2010

MyEDB SQL One Liner

In this case the use case is to reduce the quantity of each product variation ("ron" in myedb speak), i.e. items in a shopping cart, when the total transaction is finalized. The following code can be placed in a transaction inside a MySQL 5.x stored procedure:


update property natural join int_prop natural join entity_property natural join entity
inner join medb_transaction on entity.eid = medb_transaction.eiddst and entity_property.ron = medb_transaction.ron
and property.prop_group_id = medb_transaction.prop_group_id
set int_val = int_val - qty
where medb_transaction.eidsrc = 8 and property.prop_id = 15

The prop_id 15 is the ID of the 'quantity' property. eidsrc is passed as a parameter to the stored procedure and represents the user id (or "eid" for entity id in myedb speak ;) ).

Wednesday, March 10, 2010

New myedb.com Domain for Framework

My first post to describe my MyEDB (My Entity Database) framework/CMS was placed on a holding site at netfirms:

This is my stand-in site to promote my concept of an "Entity Database" which is more than a relational database -- it gives the DB designer more flexibility in setting up and tearing down entities. I call it and the supporting code framework MyEDB for My Entity DB.



It does away with the traditional notion of entity relationships, and just focuses on pure entities, no relationships and the headaches they cause Database designers. The purpose for relationships has evolved from an ingenuous desire to model entities and their relationships into being merely an optimization device. My framework gets rid of the pretense. All optimization is stored natively through the use of single type tables.

One added benefit of this static architecture is that of being essentially a low level database per se, but one that is accessible to database designers.

Combine this with an elegant PHP-based RESTful MVC framework, and all that's left is defining inputs and outputs and coding them. And the effort of coding the input/output wire-ups simply scales to the level of your requirements -- i.e. pay per requirement.
Requirements can be defined as any of the following:
- Create a form for Inserting, updating, or deleting an entity (e.g. a customer record)
- Create a new view of the entity, purely for display (e.g. a product, or any entity. Examine one of your Excel spreadsheets rows for examples of "entities")
- Build search functionality for all your entities or only a subset



Copyright 2010