Data Base Management
-
@JaredBusch said in Data Base Management:
What made the DBF files? A file extension is not the most helpful thing because what it contians could vary depending on what was creating it.
I believe its a SQL database
-
the way it works, is any changes in the newer software versions are sent to a sql database and then translated into a folder, and then when the site sends new configurations the folder copies over another folder which is then used by the terminal to load the new configurations (i.e, New items, prices, new modifiers etc.)
-
@WrCombs said in Data Base Management:
@JaredBusch said in Data Base Management:
What made the DBF files? A file extension is not the most helpful thing because what it contians could vary depending on what was creating it.
I believe its a SQL database
I assume that you mean SQL Server created database file then.
In that case MS Access, or SQL server itself.
-
@JaredBusch said in Data Base Management:
@WrCombs said in Data Base Management:
@JaredBusch said in Data Base Management:
What made the DBF files? A file extension is not the most helpful thing because what it contians could vary depending on what was creating it.
I believe its a SQL database
I assume that you mean SQL Server created database file then.
In that case MS Access, or SQL server itself.
Thanks for the input, Ill look into it.
-
@WrCombs said in Data Base Management:
the way it works, is any changes in the newer software versions are sent to a sql database and then translated into a folder
That's not how anything works.
More likely, this means.
- New release comes in as a SQL update statement.
- SQL update is ran to update SQL database itself.
- Final part of release kicks off an export of SQL data to a folder structure.
None of this has anything to do with a DBF directly though.
So if you want more information, post some real details.
But the short answer will still be use MS Access or SQL Server.
-
@JaredBusch said in Data Base Management:
@WrCombs said in Data Base Management:
the way it works, is any changes in the newer software versions are sent to a sql database and then translated into a folder
That's not how anything works.
More likely, this means.
- New release comes in as a SQL update statement.
- SQL update is ran to update SQL database itself.
- Final part of release kicks off an export of SQL data to a folder structure.
None of this has anything to do with a DBF directly though.
So if you want more information, post some real details.
But the short answer will still be use MS Access or SQL Server.
aye aye captian
-
@WrCombs how about telling us how the company currently does whatever you're talking about.
Do they really - something sent to the DB, then somehow translated to folder? then, then, then, etc?
Yeah - I barely understand what JB said - I've had only the tiniest of exposure to DB management/etc.
-
@Dashrender said in Data Base Management:
@WrCombs how about telling us how the company currently does whatever you're talking about.
Do they really - something sent to the DB, then somehow translated to folder? then, then, then, etc?
Yeah - I barely understand what JB said - I've had only the tiniest of exposure to DB management/etc.
the way it was explained to me was : We make changes in our software. It is sent to SQL database , when we "Refresh" the data and send out information it goes to folder "A" and then copies over Folder "B" which is where the terminals pull their information.
in older versions - The dbfs are created by the software and help in folder "A" and copied over to folder "B" when refreshed and sent out.but Im not in the mood to argue with people. This is how it was explained that's all I know.
If you want to help me understand it great, if you want to put me down fuck off. -
@WrCombs said in Data Base Management:
@Dashrender said in Data Base Management:
@WrCombs how about telling us how the company currently does whatever you're talking about.
Do they really - something sent to the DB, then somehow translated to folder? then, then, then, etc?
Yeah - I barely understand what JB said - I've had only the tiniest of exposure to DB management/etc.
the way it was explained to me was : We make changes in our software. It is sent to SQL database , when we "Refresh" the data and send out information it goes to folder "A" and then copies over Folder "B" which is where the terminals pull their information.
in older versions - The dbfs are created by the software and help in folder "A" and copied over to folder "B" when refreshed and sent out.but Im not in the mood to argue with people. This is how it was explained that's all I know.
If you want to help me understand it great, if you want to put me down fuck off.Right - so with what you just said - at no time does someone manually touch the DB files.
Your Software is what updates the SQL DB. Then the refresh process creates the changes send to Folder A, then the overwrite of folder B happens by another process.
I see no point where you need to actually deal with or worry about the DB files themselves.
-
I've used MS SQL management studio to manage MS SQL databases.
-
@Dashrender said in Data Base Management:
@WrCombs said in Data Base Management:
@Dashrender said in Data Base Management:
@WrCombs how about telling us how the company currently does whatever you're talking about.
Do they really - something sent to the DB, then somehow translated to folder? then, then, then, etc?
Yeah - I barely understand what JB said - I've had only the tiniest of exposure to DB management/etc.
the way it was explained to me was : We make changes in our software. It is sent to SQL database , when we "Refresh" the data and send out information it goes to folder "A" and then copies over Folder "B" which is where the terminals pull their information.
in older versions - The dbfs are created by the software and help in folder "A" and copied over to folder "B" when refreshed and sent out.but Im not in the mood to argue with people. This is how it was explained that's all I know.
If you want to help me understand it great, if you want to put me down fuck off.Right - so with what you just said - at no time does someone manually touch the DB files.
Your Software is what updates the SQL DB. Then the refresh process creates the changes send to Folder A, then the overwrite of folder B happens by another process.
I see no point where you need to actually deal with or worry about the DB files themselves.
So that we can see when changes were made: I've had multiple sites call in about things not working only to find out that somone changed the Settings and refreshed - Viewing database files helps us tell the site what happened and how to change it back.
That's really all we need it for.
Lets say a printer is set up to be on com port 2 and someone moves it to one in the office but not on the terminal it's self.
I need to be able to see the change so I can get that printer working again.
Does that make sense ? -
Being an old timer .DBF means to me dBase/Fox Pro/Clipper Database File, If that's the case then you can try http://www.alexnolan.net/software/dbf.htm
-
-
@WrCombs said in Data Base Management:
but Im not in the mood to argue with people. This is how it was explained that's all I know.
If you want to help me understand it great, if you want to put me down fuck off.Just important to not repeat things that make no sense. You know that the people you work with don't know this stuff and just say random things. So repeating it as if it might be accurate will cause problems. You should present it as "I was told X by people who don't understand IT, and I need to do Y..."
Don't present it as if you think that they might be correct. They might be, but it isn't very likely. But there is likely something to be discovered if we read into what they describe.
-
@scottalanmiller said in Data Base Management:
@WrCombs said in Data Base Management:
but Im not in the mood to argue with people. This is how it was explained that's all I know.
If you want to help me understand it great, if you want to put me down fuck off.Just important to not repeat things that make no sense. You know that the people you work with don't know this stuff and just say random things. So repeating it as if it might be accurate will cause problems. You should present it as "I was told X by people who don't understand IT, and I need to do Y..."
Don't present it as if you think that they might be correct. They might be, but it isn't very likely. But there is likely something to be discovered if we read into what they describe.
Fair enough. This is just the way I'm told this is how it works- From the understanding of Point of sale.
-
@WrCombs said in Data Base Management:
@Dashrender said in Data Base Management:
@WrCombs said in Data Base Management:
@Dashrender said in Data Base Management:
@WrCombs how about telling us how the company currently does whatever you're talking about.
Do they really - something sent to the DB, then somehow translated to folder? then, then, then, etc?
Yeah - I barely understand what JB said - I've had only the tiniest of exposure to DB management/etc.
the way it was explained to me was : We make changes in our software. It is sent to SQL database , when we "Refresh" the data and send out information it goes to folder "A" and then copies over Folder "B" which is where the terminals pull their information.
in older versions - The dbfs are created by the software and help in folder "A" and copied over to folder "B" when refreshed and sent out.but Im not in the mood to argue with people. This is how it was explained that's all I know.
If you want to help me understand it great, if you want to put me down fuck off.Right - so with what you just said - at no time does someone manually touch the DB files.
Your Software is what updates the SQL DB. Then the refresh process creates the changes send to Folder A, then the overwrite of folder B happens by another process.
I see no point where you need to actually deal with or worry about the DB files themselves.
So that we can see when changes were made: I've had multiple sites call in about things not working only to find out that somone changed the Settings and refreshed - Viewing database files helps us tell the site what happened and how to change it back.
That's really all we need it for.
Lets say a printer is set up to be on com port 2 and someone moves it to one in the office but not on the terminal it's self.
I need to be able to see the change so I can get that printer working again.
Does that make sense ?It makes sense. But it isn't nearly enough info. That you have database files called .dbf doesn't give us anything to go on. DBF files are not generic. So we get what you are trying to ask, but we don't have enough to actually tell you what you can do.
-
@WrCombs said in Data Base Management:
@scottalanmiller said in Data Base Management:
@WrCombs said in Data Base Management:
but Im not in the mood to argue with people. This is how it was explained that's all I know.
If you want to help me understand it great, if you want to put me down fuck off.Just important to not repeat things that make no sense. You know that the people you work with don't know this stuff and just say random things. So repeating it as if it might be accurate will cause problems. You should present it as "I was told X by people who don't understand IT, and I need to do Y..."
Don't present it as if you think that they might be correct. They might be, but it isn't very likely. But there is likely something to be discovered if we read into what they describe.
Fair enough. This is just the way I'm told this is how it works- From the understanding of Point of sale.
Yup, we understand that that is the case. It's just wording it so that we know that you know that that is the case
-
@scottalanmiller said in Data Base Management:
@WrCombs said in Data Base Management:
@Dashrender said in Data Base Management:
@WrCombs said in Data Base Management:
@Dashrender said in Data Base Management:
@WrCombs how about telling us how the company currently does whatever you're talking about.
Do they really - something sent to the DB, then somehow translated to folder? then, then, then, etc?
Yeah - I barely understand what JB said - I've had only the tiniest of exposure to DB management/etc.
the way it was explained to me was : We make changes in our software. It is sent to SQL database , when we "Refresh" the data and send out information it goes to folder "A" and then copies over Folder "B" which is where the terminals pull their information.
in older versions - The dbfs are created by the software and help in folder "A" and copied over to folder "B" when refreshed and sent out.but Im not in the mood to argue with people. This is how it was explained that's all I know.
If you want to help me understand it great, if you want to put me down fuck off.Right - so with what you just said - at no time does someone manually touch the DB files.
Your Software is what updates the SQL DB. Then the refresh process creates the changes send to Folder A, then the overwrite of folder B happens by another process.
I see no point where you need to actually deal with or worry about the DB files themselves.
So that we can see when changes were made: I've had multiple sites call in about things not working only to find out that somone changed the Settings and refreshed - Viewing database files helps us tell the site what happened and how to change it back.
That's really all we need it for.
Lets say a printer is set up to be on com port 2 and someone moves it to one in the office but not on the terminal it's self.
I need to be able to see the change so I can get that printer working again.
Does that make sense ?It makes sense. But it isn't nearly enough info. That you have database files called .dbf doesn't give us anything to go on. DBF files are not generic. So we get what you are trying to ask, but we don't have enough to actually tell you what you can do.
I thought .dbf was just a generic file name
-
@WrCombs said in Data Base Management:
@scottalanmiller said in Data Base Management:
@WrCombs said in Data Base Management:
@Dashrender said in Data Base Management:
@WrCombs said in Data Base Management:
@Dashrender said in Data Base Management:
@WrCombs how about telling us how the company currently does whatever you're talking about.
Do they really - something sent to the DB, then somehow translated to folder? then, then, then, etc?
Yeah - I barely understand what JB said - I've had only the tiniest of exposure to DB management/etc.
the way it was explained to me was : We make changes in our software. It is sent to SQL database , when we "Refresh" the data and send out information it goes to folder "A" and then copies over Folder "B" which is where the terminals pull their information.
in older versions - The dbfs are created by the software and help in folder "A" and copied over to folder "B" when refreshed and sent out.but Im not in the mood to argue with people. This is how it was explained that's all I know.
If you want to help me understand it great, if you want to put me down fuck off.Right - so with what you just said - at no time does someone manually touch the DB files.
Your Software is what updates the SQL DB. Then the refresh process creates the changes send to Folder A, then the overwrite of folder B happens by another process.
I see no point where you need to actually deal with or worry about the DB files themselves.
So that we can see when changes were made: I've had multiple sites call in about things not working only to find out that somone changed the Settings and refreshed - Viewing database files helps us tell the site what happened and how to change it back.
That's really all we need it for.
Lets say a printer is set up to be on com port 2 and someone moves it to one in the office but not on the terminal it's self.
I need to be able to see the change so I can get that printer working again.
Does that make sense ?It makes sense. But it isn't nearly enough info. That you have database files called .dbf doesn't give us anything to go on. DBF files are not generic. So we get what you are trying to ask, but we don't have enough to actually tell you what you can do.
I thought .dbf was just a generic file name
All extensions are just generic file naming conventions. But databases cannot be generic. So the extension tells you one thing...
That the person naming it intended for you to assume that it is data for a database.
That's it. It doesn't tell you what kind of data, that it is really a database, that it is for a specific database, etc. Nothing. It could be a text file, a Word doc, an XML doc, malware, a JetDB data file, a SQL Server data file, dBase, FoxPro, Clipper, or one of thousands of things we aren't thinking of.
It's likely to be something legitimate and normal. But that leaves about a dozen totally unrelated options.
-
Keep in mine that database = "place to store and retrieve structured data". That's it. Nothing more, nothing less. So knowing that something is "a database" only tells you that the data is not completely unstructured, nothing else. That's not much to go on.
