|
It's a long story, Steven, but here goes... The CF site I'm writing is an extension of ASP site, which was written by a programmer who's no longer available. I tried to write the extension of his site in ASP at first, but I was never able to establish a development environment to work in because of the special way he wrote his site: all the data access takes place through COM objects he wrote in Visual Basic, and I could never get them running (nor re-create them) on any of my PCs at home - even after consulting with the original programmer by e-mail and long distance phone conversation, and many hours of gnashing my teeth and tearing my hair. So I persuaded the company president (it's a small company) to let me write the extension in CF, in which I had a couple of years experience (though that was in the days of CF version 5). It was my firm impression based on what I was told about the existing site that the DB in question (which belonged to the first programmer's start on this additional functionality, which I was told to trash and start over) was my own to do as I pleased with, and at one point I deleted a column I saw I would have no use for. Later on, I learned that a particular function on a second(!) ASP site written by the first programmer (that I had not been told about) had stopped working, and by far the most likely cause is the absence of the column I had deleted. It's not a huge problem so far - most of the second site, and the evidently all of the first (far larger) site still works, So I was assigned the task of simply adding that functionality to my new site. The functionality in question is a list of court reporters and their passwords - evidently not used in the first two sites as far as I can tell at present, and logically part of my new site, which enables court reporters to report back on the results of their court reporting job once they get home. Needless to say, I put back the deleted column, but I had made no record of its datatype and width - and chances are that's built into the COM object in such a way that it grinds to a halt if I don't get those things exactly as they were before. And I don't dare try to rebuild the COM object! (There may be backups of the original table somewhere - I'm looking, but it may not be worth it.) Unlike most of the rest of my app, which is a lot more complicated, this particular task lent itself to easy solution via a CFGRID, which I wrote over the week-end. However, in the process, I had to make some other changes to the structure of the reporters table - one requested by the boss, and another required to make the CFGRID work - namely the removal of a sequential field which had been defined as its key. It may have been an auto-increment (a.k.a. 'identity') column at one point, but it is no longer. Even when I include it as an invisible column in the CFGRID, it does not automatically update. So, instead of including it as a visible, updateable column requiring the user to come up with the next number himself, I decided to get rid of it and go with a new key (the reporter's login ID). So now the structure of the table will be VERY different. No big deal? Not if it's really true that this table is independent of everything else in the two ASP sites except for the piece that no longer works. But I don't dare take that chance! Various of its columns are mentioned several times in the classes from which the COM objects used by the two ASP sites were built (both of them use objects in the same gigantic DLL to reference their data). I hope the above was interesting! Peyton P.S. In general, there seems to be a problem in our two sites referencing the same data. For example (get ready for mention of Rip Van Winkle's rusty flintlock rifle:) both sites need to access data in FoxPro for DOS, which turns out to be impossible if we're aiming at the same FoxPro DB. My site does not need to be up-to-the minute, though, so we''ll be getting along with nightly copies of the relevant FoxPro tables. Even if I were to get the original reporters' table back exactly as it was, I'm not convinced we wouldn't still be step on each other's toes. I can see from the other programmer's Visual Basic code that he's opening it read-only, but that doesn't mean he drops the connection, and I myself know of no ASP equivalent of the CF Administrator to specify that that be done. For all I know, it would not be necessary anyway with (multi-threaded?) SQL Server. But this way seems safer. And more practical given the limitations on time and resources. -----Original Message------------------------------------------------------------------ Annual Sponsor FigLeaf Software - http://www.figleaf.com To unsubscribe from this list, manage your profile @ http://www.acfug.org?fa=login.edituserform For more info, see http://www.acfug.org/mailinglists Archive @ http://www.mail-archive.com/discussion%40acfug.org/ List hosted by http://www.fusionlink.com ------------------------------------------------------------- |
- Re: [ACFUG Discuss] Why Clone the SQL Server Database? Peyton Todd
