It would be nice if MS did this

Had 1 more column in the database window called "Last Compiled"

When you compile the front end all of the "Modified" timestamps reflect
the last date/time of the compile...not when the developer modified the
files.

This destroys the history of work a developer did.

If I had any pull with MS I'd request they make a new column for compile
dates. I could compare the last dates of compile to the last modified file.

I don't know if you find it annoying you can't have a history of
changes. I do.

re: It would be nice if MS did this

I agree.. The dates are fairly meaningless, and I never use them. Pretty
sure you need to use source code control to be able to track the modified
info.


"Salad" <oil@vinegar.comwrote in message
news:13hc90a2rercl3f@corp.supernews.com...

re: It would be nice if MS did this

On Wed, 17 Oct 2007 08:02:33 -0700, Salad <oil@vinegar.comwrote:

Same problem if you compact a db.

And while they're at it, wander on over to that other building on
campus, and give us a LastModified property for SQL Server objects as
well.

-Tom.

re: It would be nice if MS did this

Tom van Stiphout wrote:I was thinking about that additional column. It could be used to store
the date a table structure is modified as well. You'd then be able to
know when an object was created, when code/SQL where modified and data
changed in a table, and when the code was last compiled or a table
structure changed.

And I read your post. It doesn't seem like it should be that big of a
deal for MS to do it in Access or SQL Server.

re: It would be nice if MS did this

ARC wrote:
Which adds more work when adding column would work just as well.

I even wish, when I link or import data from another database it would
display the dates as well in the import window. When you compile and
wipe out the dates they really do become meaningless.

re: It would be nice if MS did this

On Thu, 18 Oct 2007 00:10:25 GMT, "ARC" <PCESoft@PCESoft.invalid>
wrote:

However, if you read about the many restrictions for using SourceSafe
to store individual Access objects, that route is no longer very
attractive.

And storing SQL Server objects in SourceSafe: Ha!

-Tom.

re: It would be nice if MS did this

Salad <oil@vinegar.comwrote in
news:13hc90a2rercl3f@corp.supernews.com:
This is a consequence of the implementation of the VBE and the
monolithic save model for the VBA project that was first introduced
in A2K.

It was just a stupid idea, and I can't understand the logic behind
it. No explanation that has ever been given ("it's to decrease the
incidence of corruption." Eh? How does storing it all in a huge BLOB
field instead of a whole bunch of individual records, one for each
module, decrease the incidence of corruption?) makes any sense to me
at all.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

re: It would be nice if MS did this

David W. Fenton wrote:That may be a consequence. But it would be nice to have an extra date
column so history isn't lost. The guys who write Access aren't
developing with Access.

There's another things I'd also change. For example, when going to the
design wizard of a form all tables and queries are mixed. Tables are
preceeded with the word Tables, queries with Queries. But if you go
into Query/New and click on Add tables the tables have a tab, queries
another. That is so much nicer. If you are going to tell us what is a
table and what is a query then put it in a separate column and put the
object name first.
I suppose Michka could answer that.

I don't even like the object type options displayed vertically and the
action type displayed horizontally in the database window. It was like
someone went of their way to "shake things up". I liked them like they
were in '97.

Like the war in Iraq, nobody asked for my opinion.