<p>c# + sql server: I have to import a few tables from Access into sql server. The new sql server tables are already defined and created. The Access tables have primary key - foreign key relationships that have to be maintained. I would like to have the new sql tables use identity values for the primary keys, but I can't easily load the legacy rows and maintain the relationships if I do that. I could possibly load the data using identity_insert but I have to back way out of my ORM software (subsonic) to do that. Perhaps I can make my new primary keys non-identity types, but then there is the hassle of generating unique ids for all the rows I add later. I'm sure this has a decent solution out there somewhere.</p>

In a past project in C I worked on, we went down the road of implementing our own memory management routines for a library ran on a wide range of platforms including embedded systems.  The library also allocated and freed a large number of small buffers.  It ran relatively well and didn't take a large amount of code to implement.  I can give you a bit of background on that implementation in case you want to develop something yourself.
The basic implementation included a set of routines that managed buffers of a set size.  The routines were used as wrappers around malloc() and free().   We used these routines to manage allocation of structures that we frequently used and also to manage generic buffers of set sizes.  A structure was used to describe each type of buffer being managed.  When a buffer of a specific type was allocated, we'd malloc() the memory in blocks (if a list of free buffers was empty).  IE, if we were managing 10 byte buffers, we might make a single malloc() that contained space for 100 of these buffers to reduce fragmentation and the number of underlying mallocs needed.
At the front of each buffer would be a pointer that would be used to chain the buffers in a free list.  When the 100 buffers were allocated, each buffer would be chained together in the free list.  When the buffer was in use, the pointer would be set to null.  We also maintained a list of the "blocks" of buffers, so that we could do a simple cleanup by calling free() on each of the actual malloc'd buffers.
For management of dynamic buffer sizes, we also added a size_t variable at the beginning of each buffer telling the size of the buffer.  This was then used to identify which buffer block to put the buffer back into when it was freed.  We had replacement routines for malloc() and free() that did pointer arithmetic to get the buffer size and then to put the buffer into the free list.  We also had a limit on how large of buffers we managed.  Buffers larger than this limit were simply malloc'd and passed to the user.  For structures that we managed, we created wrapper routines for allocation and freeing of the specific structures.
Eventually we also evolved the system to include garbage collection when requested by the user to clean up unused memory.  Since we had control over the whole system, there were various optimizations we were able to make over time to increase performance of the system.  As I mentioned, it did work quite well.