By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,493 Members | 1,176 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,493 IT Pros & Developers. It's quick & easy.

It would be nice if MS did this

P: n/a
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.
Oct 17 '07 #1
Share this Question
Share on Google+
7 Replies


P: n/a
ARC
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" <oi*@vinegar.comwrote in message
news:13*************@corp.supernews.com...
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.
Oct 18 '07 #2

P: n/a
On Wed, 17 Oct 2007 08:02:33 -0700, Salad <oi*@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.
>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.
Oct 18 '07 #3

P: n/a
Tom van Stiphout wrote:
On Wed, 17 Oct 2007 08:02:33 -0700, Salad <oi*@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.
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.
>>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.
Oct 18 '07 #4

P: n/a
ARC wrote:
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.
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.

>

"Salad" <oi*@vinegar.comwrote in message
news:13*************@corp.supernews.com...
>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.

Oct 18 '07 #5

P: n/a
On Thu, 18 Oct 2007 00:10:25 GMT, "ARC" <PC*****@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.
>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" <oi*@vinegar.comwrote in message
news:13*************@corp.supernews.com...
>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.
Oct 18 '07 #6

P: n/a
Salad <oi*@vinegar.comwrote in
news:13*************@corp.supernews.com:
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.
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/
Oct 19 '07 #7

P: n/a
David W. Fenton wrote:
Salad <oi*@vinegar.comwrote in
news:13*************@corp.supernews.com:

>>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.


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.
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.
>
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.
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.
Oct 20 '07 #8

This discussion thread is closed

Replies have been disabled for this discussion.